Orbital Parameters Topical Analysis and Parameterization

My Standard Caution About Examples applies to this page.

Introduction

This example demonstrates how relational database design principles can be applied to the analysis of topics and identification of associated parameters.  Because this methodology implements strict Set Theory it should be at least close to reproducible, and is capable of a substantially mitigating cognitive bias in the aggregation of data that are pertinent to many different product lines and tasks.  The method is particularly useful when data are originally presented in tabular form.

The following discussion generally follows Shlaer and Mellor (SM) as referenced inthe relational table criteria.  It concentrates on the data to enhance exposure of the underlying technical concepts.  Some aspects of the problem might be more efficiently approached “from first principles”…but we can’t assume that individual System Engineers have the infinite breadth of technical expertise that will always permit that.  This approach provides a paradigm for bootstrapping into a reasonable familiarity with the material.  In one form or another, I have used it when coming up to speed on almost every new System Engineering assignment for the last 30 years.

In contrast with the Combustion Products example, this example does not progress in linear fashion from identification of topics to identification of parameters.  The reader is exposed to the full onslaught of sausage production, which is often messy while the analyst1 comes up to speed on the technical material.  Other practioners might approach these in a different order or, based on a different understanding of the technical material, arrive at slightly different conclusions that might improve on mine.

Original Data

The original data set2 is shown in Table 1.

Table 1: Reference Table 2-1 Orbital Characteristics of the Planets

Normal database design will typically tabulate data with attributes (fields) as the columns, and records as rows.  It is possible to work with either orientation, but if we transpose the table we’ll be able to add more “bodies” than just the nine planets3.  Either way can be made to work, but most database software makes it easier to add rows than columns.

The transposition is shown in Table 2.

Table 2: Reference Table 2-1 Transposition to Standard Orientation

Generally following SM, I’ll first look to identify fields in Table 2 that have multiple values4, working to the single value criterion.  The results (shown in Table 3) stem from two basic sources:

  1. The footnotes, which implicitly state that two cells (for Axial Rotational Period) actually have two values.  In both cases, the second value is found in a footnote to the original table.  The resolution adds a column and two rows to make the distinctions.  Note that this effectively incorporates the footnotes, which are not subsequently shown in this analysis.Table 3 also highlights a restatement of the qualitative nature of Saturn’s period of rotation, to whit “near equator”.  It is not possible to interpret this value from the data given.  It is my general practice to use the NULL database value to indicate “missing” data, but that will be postponed until resolution of other NULL field values, below.
  2. One cell indicates a “retrograde” rotation.  With a bit of research, in this case, using BMW 5, it turns out that when the word “retrograde” is applied to the axial rotation of an orbiting body it means that the rotation is opposite the direction of the orbit itself.  The opposite of retrograde is “direct”.  I have added a column and populated it accordingly for each row coding6 it as “+” for direct and “-” for retrograde7.
Table 3: Elimination of Compound Values (Part I)

Note that the word “retrograde” disappears from the Axial Period column when the Rotational Direction column is added.  This is the first hint that the table covers more topics than the original title suggests: axial rotation is, strictly speaking, not an orbital characteristic.  It is a body characteristic that is independent of the orbital parameters themselves8.

Still following SM, Table 4 shows the elimination of structure internal to the data cells (the atomic data criterion).  Internal structure means that data have to be decoded on the fly during retrieval, and introduce a significant opportunity for errors of transcription, especially when the units are mixed (which they are here)9.  Table 4 highlights the elimination of that internal structure for two columns: orbital inclination is now shown in decimal degrees (no minutes of arc) and the Axial Rotational Period is now shown in seconds.  It has to be noted that an implicit question of actual precision is difficult to address with this step, and the resulting data should almost certainly be validated from some other source before production use is made of these results.

Table 4: Reduction of Internal Structure

Again following SM, Table 5 provisionally selects a combination of columns by which we can select exactly one desired row (a first cut at meeting the key criterion).  In theory, it is possible to have more than one such combination: database design will quasi-arbitrarily select one combination as the “primary key” (shown in bold text in the tables).  Here, we’d clearly like to consider the name of the planet to be a key…but there are two entries each for Saturn and Jupiter (highlighted in Table 6).  This is a significant issue: some practices will arbitrarily add a column that is assured unique by the database “engine”, but this is very poor practice, rife with potential for data integrity errors.  Additional work must be performed before a Primary Key can finally be selected.

Table 5: Provisional Identification of Primary Key (Unique Row Selection)
Table 6: Identification of Provisional Primary Key Violations

The primary key violations (highlighted in Table 6) are resolved by splitting the table into two pieces.  One is (provisionally) the orbital parameters (Table 7).  The other (Table 8) collects the (provisional) rotational characteristics.  BOTH tables contain the (provisional) Primary Key.  This column can be used to “join” the two tables, recovering the original relationship.  This notion of “splitting across the Primary Key” is fundamental to resolving the so-called “Primary Key Violations”.

Table 7: Resolving Primary Key Violations

The implication of the table split operation is that there will be more than one Topic, each topic having a uniquely associated set of parameters.  The discovery of this information is a primary objective of this exercise.  In all cases, only ONE of the split tables will retain the (still provisional) Primary Key in isolation; all the other resulting tables will require at least one more column in combination with the original column, forming a “compound” Primary Key.

In Table 8, the new table’s Primary Key is comprised of the first two columns on the left.  Table 8, however, is entirely “provisional”, and not all of the criteria are met.  As will seen below, additional work is required before it meets standard relational criteria.

Table 8: Resolving Primary Key Violations, Part II (Provisional Table: Body Physical Characteristics)

It was probably clear to the reader from first inspection that some of the column headers (originally row headers) contained equations that related the values to those in other columns (Perihelion and Aphelion Distances).  It may, however, have been less apparent that many columns step on each other’s toes (they contribute to each other’s calculation).  The non-transitive criterion applies to these columns.  Table 9 highlights the columns that are related in that manner.

Table 9: Identification of Transitive Relationships Part I

Specifically:

  • Given that the orbits are all elliptical (and, in the general two-body analysis of closed orbits, they are), the Perihelion and Aphelion distances can be calculated directly from the semi-major axis, eccentricity and mass of the sun10.  So too, can the orbital velocity and period of revolution.  This all follows from analytic geometry (due to Kepler).
  • The two orbital velocities are mere conversions between two different sets of units.

The first step in resolving these issues is to simply remove the redundant columns (see Table 10).  Note that this cut the storage requirements by almost a third…not too important for this little bit of data, but pretty significant for situations in which more rows are used!  The price for that reduction is CPU time required to recalculate the deleted values when, as, and if they are needed.  The rest of the steps required will be supplied when finally defining frames of reference, below.

Table 10: Resolution of Transient Relationships, Part I

Table 11 loosely returns to the question of “correct attribution“: it is increasingly clear that some of the columns aren’t about the orbit, but about the planet.  Those columns are moved to that provisional table (see Table 12) for subsequent handling.  (The death knell for these columns will be sounded with Table 14, below.)

Table 11 also highlights that NULL value for the Earth’s Mean Longitude of Ascending Node.  Understanding that issue is a bit easier now: some of the excess columns have been removed, focusing the table more closely on the parameters associated with how planets move around the Sun (that is, their orbit).

Table 11: Identification of Incorrect Attribution and NULL Interpretation
Table 12: Identification of Incorrect Attribution

After further research, it turns out that the parameters defined in the original table were given in a frame of reference where the three dimensions are defined by the orbit of the Earth around the sun: the “ecliptic”.  The ascending node is that point where a planet’s crosses the plane of the ecliptic, in which Earth orbits.  The use of that frame of reference means that the Earth itself never has a value for Longitude of the Ascending Node, which fully explains the empty value in that cell of the original table.  We’ll use the IEEE “NaN” for that value, because Infinity is not a number and we want to reserve NULL to code “TBD”.  This also makes plain that we could specify the orbits in other frames of reference.  Table 13 creates a new table for Orbital Frames of Reference.

Table 13: Resolution of Incorrect Attribution (Table: Orbital Frame of Reference)

Note that Table 14 introduces a kind of “Pseudo-Primary Key”: the “system name”.  The true Primary Key is the combination of “Center” and “Reference Plane”.  If designing an actual database, I’d place a “unique index” on that combination to ensure it was never duplicated.

Table 14 adds a “pointer” column to the table of orbital column to indicate which reference frame is being used to supply values for which orbital parameter.  We could (eventually) go on to specify the orbital parameters for the nine planets in other frames of reference, so we add that pointer column to the provisional Primary Key.  The (augmented) Primary Key makes it very clear that the columns dealing with rotation of the planet about it’s own axis are out of place in this table: they don’t care about that particular frame of reference.

Table 14: Resolution of Incorrect Attribution and NULL

The problem with those two “rotation” columns is that they don’t really belong with some of the rows in the (provisional) table of planetary rotations.  We already knew that Table 12 had multiple entries for the provisional Primary Key (two each for Jupiter and Saturn)…moving two rotation columns (axis and direction) made things worse!  We can take this opportunity to resolve the whole thing by splitting that provisional table again, as shown in Tables 15 and 16.  Table 15 addresses the issue of Atmospheric Rotation which may, or may not, be different that the rigid body rotation of the planet.  Table 16 deals with the properties of the body itself (under all that gas).  As before, NULL is used to indicated data that could feasibly be entered, but for which the values are unknown.

Table 15: Resolution of Incorrect Attribution (Table: Body Atmospheric Rotation)
Table 16: Resolution of Incorrect Attribution (Table: Body Physical Characteristics)

An argument could be made that the “NaN” value in Table 14 is redundant with the combination of columns forming the new primary key because it “transits” by way of the implications of Table 13.  In that argument, the entire set of table is incompatible with the relational paradigm.  I’d be willing to entertain counter-proposals, secure in the knowledge that data integrity is not challenged by the approach taken here, and the data end up in a form very familiar to the Orbital Mechanics among us11.

It is interesting (maybe!) to note that we’re now up to four tables, where we originally had just one.  Each table is now more tightly focused on a single topic.  Significant progress has been made to identify and remove redundant data, reducing storage requirements and reducing the opportunity for errors in populating future entries.

Continuing to turn the various cranks, we can (and should) address the cryptic “J2000” in the True Longitude of Perhihelion: the direction of the vector from the center of the orbit to it’s closest approach to that center, highlighted in Table 1712.  The earlier research (BMW, leading up to Table 10) revealed that the combination of columns (orbital parameters) of this formulation are not constants, even though they appear to be presented as such.  They change over time; the time at which they apply is referred to as an “epoch”; the orbital parameter values for heavenly bodies are published in a document called an “ephemeris”.  Table 18 pivots the cryptic value out of the last column into a new column specifying the ephemeris for which the current values are applicable.

Table 17: Identification of Compound Value

In addition to the texts referenced above, JPL’s Horizons web site supports interpretation of this parameter set as applicable only to the classical analytical geometry, more or less as developed by Kepler centuries ago.  Table 18 specifies this explicitly.  JPL’s FAQ discussion implicitly suggests that the notion of formally published ephemerides is essentially obsolete, since their high-precision calculations can be executed for any arbitrary epoch.  I stumbled onto the JPL site by guessing that “J2000” refers to an ephemeris more recent than BMW’s 1969 reference, searching the interwebs for that combination of terms< I don’t normally consider the results of interweb search to be authoritative, but I’m willing to take a flyer on JPL.[/efn_note].

Table 18: Resolution of Compound Value (Column: Ephemeris); Table naming “Two-Body Closed Orbit Parameters”.

Conclusion

The example analysis is now substantially complete.  Four tables exist, each of which represents exactly one topic: Two-Body Closed Orbit Parameters, Body Physical Characteristics, Body Atmospheric Rotation, and Orbital Frame of Reference.  Each table’s structure (column headings) defines the parameters associate with the specific topic, and we have identified the data yet to be determined so that tasks can be identified13.

We can test that hypothesis a bit, by trying to add more data.  Tables 19 through 21 extend three of the four tables to accommodate the Moon (Luna), orbiting in a frame of reference with the Earth at the center.  Again, “NULL” values indicate data not known at the time of population, from which “taskers” can be defined.  The moon having no atmosphere, no extension is required for the fourth table (Body Atmospheric Rotation).

Table 19: Extension (New Reference Frame)
Table 20 Extension of Rigid Body Characteristics
Table 21: Extension of Orbital Parameters
Footnotes
  1.   Me![↩]
  2. Table 2-1, “TRW Space Data”; Barter, Nevill J (ed.), TRW (1992)[↩]
  3.   The data originated before Pluto was demoted[↩]
  4.   definition (1).[↩]
  5. ”Fundamentals of Astrodynamics” by Bate, Mueller, and White; Dover Publications, New York (1971).[↩]
  6. Which is not a forbidden cyphering[↩]
  7. I could as easily have used “1” and “0” respectively and, if implementing a real database, might well have done so.[↩]
  8. Rotational velocity figures into the calculation of velocity change needed during launch from a planet, but is not an orbital parameter per se.[↩]
  9. I found no less than three such errors in my transcription of data to build this page![↩]
  10. I’ll casually add that data below, just for the sake of completeness.[↩]
  11. In other words: it makes sense from a technical perspective and isn’t likely to result in any errors to people who are reasonably familiar with the technical domain.[↩]
  12. “Perihelion” generalizes to “periapsis”.  “Helion” specifically refers to a sun-centric orbit.[↩]
  13.   Furthermore, we have identified an authoritative source of data that might well be used to entirely replace the concept of the table![↩]