太陽黒点の観測のしかた デジタル編(2)データベース設計

●データベースとは

 データベースというと、何か難しいモノのように見えますが、原理は別に難しくはありません。

 データベースには様々な種類がありますが、ここではリレーショナルデータベースを説明します。
 MicrosoftAccessや、SQLServer、Oralcleなど、有名なデータベースは、すべてこのリレーショナルデータベースというタイプのデータベースです。


 リレーショナルデータベースは、データをExcelのシートのようなものに分類して収めておきます。これをテーブルと呼びます。

データを入れておくテーブル。一見すると表計算ソフトのシートのよう。

 このテーブルに格納されたデータを、いくつかのテーブルを連結したり条件で絞り込んだり、並べ替えて読み出すことができます。データを必要に応じて様々な形で読み出すことができる所が、データベースの最大の特徴です。

リレーショナルデータベースは、複数のテーブルを連結させて読み出すことができる。リレーショナルは、「テーブルを連結する」という意味。(直訳は、「関係」ですが。)

 この機能によって作られた「仮想のテーブル」を経由して読み取ることで、いつでも集計済みのデータを得ることができます。データの実体がテーブル側にあるので、テーブル側のデータを書き換えると即座にこの「仮想のテーブル」にも反映されます。
(この仮想テーブルは、書き換えができる場合(並べ替えただけの場合)と、できない場合(項目ごとに合計したような場合)があります。)

 なお、この部分は、Accessではクエリーと呼んだり、SQLServerではビューと呼んだりして、あまり統一された表現はありませんが、この部分をSQLという言語で書く点では共通しています。(SQLを書くのは結構面倒なので、さきほどの写真のように、関係図を作ると自動的にSQLを作成するツールがAccessには付いています。)


2006/11/01
●テーブル設計

 ということで、細かい話は割愛して、太陽観測データを取り扱うデータベースのテーブル設計です。

 主に次の2つのテーブルを使います。
【観測データ】…1回の観測についてのデータ
【黒点群データ】…観測によって測定された黒点群ごとのデータ

【観測データ】
フィールド名データ型説明
観測日付日付/時刻型【主キー】YYYY/MM/DDで格納
連番数値型(長整数型)【主キー】通常は0
時刻日付/時刻型HH:MM。年月日の部分は意味を持たない。
天候コード数値型(整数型)天候テーブルのコード。
雲量数値型(整数型)0〜10の11段階で記入。
シーイング数値型(整数型)シーイングレベル。
シーイング分散値数値型(単精度浮動小数点型)シーイングレベル。
透明度数値型(単精度浮動小数点型)EV値で記入。
備考テキスト型(50桁)備考を記入。
機材テキスト型(50桁)望遠鏡、フィルタ構成など。
口径数値型(長整数型)口径をmmで記載。
考察テキスト型(50桁)気がついたメモを記入。
P数値型(単精度浮動小数点型)Pを記入。
B0数値型(単精度浮動小数点型)B0を記入。
L0数値型(単精度浮動小数点型)L0を記入。
透明度数値型(単精度浮動小数点型)EV値で記入。


【黒点群データ】
フィールド名データ型説明
観測日付日付/時刻型【主キー】YYYY/MM/DDで格納
連番数値型(長整数型)【主キー】通常は0
数値型(整数型)【主キー】2006といった西暦で記入
南北種別テキスト型(1桁)【主キー】NかSを記入。
群番号数値型(整数型)【主キー】群番号。
黒点数数値型(整数型)黒点数。
緯度数値型(倍精度浮動小数点型)緯度を記入。
経度数値型(倍精度浮動小数点型)経度を記入。
緯度終了数値型(倍精度浮動小数点型)緯度終了を記入。
経度終了数値型(倍精度浮動小数点型)経度終了を記入。
群タイプテキスト型(1桁)A,B,C,D,E,F,G,H,Jを記入。
新規Yes/No型新規のときTrue。



2006/11/20
●データの登録

 観測する都度、「観測データ」のレコードを1件起こします。
 曇りや雨で観測できなかった場合も「観測データ」のレコードを起こします。
 観測できたかできなかったかを、「時刻」フィールドに時刻が記載されているか否かで判定します。

 続いて、観測できた黒点群ごとに「黒点群データ」のレコードを起こします。
 黒点群データを登録するとき、緯度、経度の情報から前回観測時に記録した緯度経度と照合し、ほぼ同一領域であれば同じ群だと判定します。
 また、既に登録されている本日のデータとも照合し、同じ領域であれば登録できないようにします。(同じ群を二重登録しないようにするため)
 


2006/11/20
●あれ? 相対数を記録しないの?

 テーブルの項目をよく見ると、相対数が記録として残されていません。
 これは、意図的に外してあります。

 というのも、相対数Rは、

 R=k(10g+f)

という、簡単な計算で求めることができるからです。

 データベース設計のセオリーの一つに「簡単な計算で求められるような項目はデータベースの項目にしてはいけない」というものがあります。

 黒点群の数は同じ日の黒点ごとのデータの件数を調べればわかります。黒点数と群数がわかれば相対数はもとまります。だから記録していません。
 ちなみに、日ごとの黒点群数と、黒点数の合計は、次のようなSQLで一覧にできます。(MicrosoftAccessのSQLでの例)
SELECT 黒点群データ.観測日付, Count(黒点群データ.群番号) AS 群番号のカウント, Sum(黒点群データ.黒点数) AS 黒点数の合計 FROM 黒点群データ GROUP BY 黒点群データ.観測日付;


 逆に、相対数を記録することで困るのが、データ内での整合性です。たとえば、3群10個で相対数が33とかだったら、どれが正しくてどれが間違いなのかの判断がつきませんね。そういった間違いを排除するためにも、不要なデータはことごとく削除していきます。

 このため、データベース内にあるデータは決してわかりやすくありません。(ここが表計算ソフトと決定的に違う部分です。)

 なお、P,B0,L0も、観測日時がわかれば計算によって求めることはできますが、算出するのに単純な加減乗除で済まないので記録データとして保存します。


2007/02/09
●主キーの割り振り

 データベースでは、唯一無二のデータを示すために主キーという固有番号を付けます。
 これで分類できなくなると、データベースにはどれか1つのデータしか入れられませんし、複数入れられるようにするには主キーを追加して、再び設計しなおさなければなりません。データベースを設計する際、データをどこまで主キーによって分類するかを事前に充分検討しておかなければなりません。(ここがデータベースの面倒な所です。)

 たとえば、黒点群データには、南北番号があります。
 北の群か南の群かは緯度の値を調べればすぐわかることなのですが、あえて分けてあります。これは、ごく希な事なのですが、北半球に現れた群が、どんどん南下して、南半球に行ってしまうといった事があります。この場合、南半球に行ってもN群で取り扱わなければなりません。そのための分類用のキーです。


2007/02/09

[戻る]