Location: [CPSC 333] [Assignments] [Clarifications of Instructions for Assignment #1] How to Define ``Latitude''
Question:
Is there a way that we can combine the independent ``quadrant'' and the numerical part of longitude and latitude, into one attribute?
As well, can we use an auxiliary definition to define a latitude once and then refer to this to define all the different attributes that are latitudes in the same way (instead of repeating all the same details, in the definition of each one of these attributes?
Answer:
Yes, as these questions suggest, ``latitude'' doesn't have one of the data types I said an ``attribute'' of something should have. On the other hand, it does seem to be a bit silly to use two attributes (one for the numerical part, and the other to represent ``N'' or ``S''), to represent ``latitude'' instead.
So, I'm going to say that it's OK, in this instance, to break one of the rules given in the lecture notes about types of attributes, by a little bit: It will be acceptable if you use ``latitude'' as an attribute but if you also give a ``type'' definition, in its data dictionary definition, in which you show that it consists of a real number and a character (that must be either ``N'' or ``S'').
Another alternative, that would be acceptable, would be to follow the instructions given in the lecture notes strictly, and then to use two attributes (one a nonnegative real number, the other a character) to represent ``latitude.''
A third alternative, which I don't like as well as either one of the first two, would be to ``represent'' latitude as a real number that happens to be 0 for something on the equator, a negative number for something that is south of the equator, and a positive number for something that's north of the equator.
I don't like (or recommend) this third alternative, because it'd be too easy for one developer to assume that a negative latitude means it's ``north,'' while another developer assumes that a negative latitude means ``south.'' Thus, if you take this last approach in order to define ``latitude,'' then please make absolutely sure that the way you interpret the sign of the number is clearly stated in your definition!
Since I've mentioned the equator - you may assume that if something lies on the equator, then its latitude is, ``0 degrees, North.''
All this holds for ``longitude,'' too (and, you can assume that something on the same line of longitude as Greenwich, England, has longitude ``0 degrees, East,'' while the line of longitude on the other side is ``180 degrees, West,'' if you're not using the sign of the numerical part of the longitude to show whether the location is to the east or to the west).
Finally, the suggestion to use an ``auxiliary definition'' in order to avoid defining ``latitude'' more than once sounds like a good idea, and it makes me wish I'd thought to define ``auxiliary definitions'' way back when I introduced ``definitions for ERDs.'' Make the ``kind'' of the helper definition ``H,'' just as it is when you use these as aids to define data flows.
This may seem useful in this instance because I'm saying it's ``OK'' to bend the rules a bit, when defining a latitude. However, I can imagine a case when multiple attributes (that really do have elementary data types) might all have the same range restrictions, units of measure, and so on, and that this might not be ``an accident;'' it'd probably be useful to give a ``helper definition'' once, and use it repeatedly, in that case as well.