多対多の（疑わしい）関係のスキーマ設計

Question

ネットワーク上のマシン構成を追跡するためのアプリケーションを作成しています。 「構成」は、システムにインストールされている製品/サービス/ OS /アプリケーションを広く定義します。いずれか1つの変更によって構成が変更されます。 情報はスキャナを使用して取得されます。データはすでに解析済みです。データを効率的に保存する方法を理解する必要があります。

基本的な考え方は、各IPが交互に

現在または過去の各設定などのデータを識別するタイムスタンプ情報及びフラグと共に構成識別子を有することになる

1. である複数種類のエントリから構成されています。したがって、各構成識別子には最大で3種類のエントリ（1-OS、2-Service、3-Applications）があります。
2. 各タイプのエントリは複数のエントリを持つことができます。例えば、タイプ1（すなわち - OS）はタイプa）Microsoft Windows XP b）Microsoft Windows 7などの複数のエントリを持つことができます。

私は次の実行に役立つ一連の適切なテーブルを定義することに固執しています目標

1. が
2. が変更を認識し、各IPのためのOS/Service.Application情報を知ろう//IP

私が取得されるデータの構成に戻すことはIPと何も変更はありませんセエントリーとそれらのタイプ識別子のt。例えば。

IP - x.y.z.w : 
Entries - Microsoft Windows XP :1(Type-OS), 
      Apache HTTP 2.3 :2(Type-Service), 
      Mozilla Firefox :3(Type - Application) 

以前の私は、構成については気にされなかったとき、ちょうど私が次のスキーム

Table ip_map : id int, ip char #Table that keeps track of IPs 
Table ip_ref: id int , ip_id references ip_map(id), t_stamp timestamp, archived bool, type smallint #Table that keeps IPs and type 
Table current_network: id int, ip_ref_id references ip_ref(id), port int, vendor, product,version #Table that stores actual entries 

に持っていたエントリを格納しなければならなかった、すなわち - 私はIPを使用してエントリを識別し、情報を入力します。

私は設定を実装する必要がある場合は、スキームは、私は、この後のステップで立ち往生しています多少

ip_map: 
+--+-------+ 
|id|ip  | 
+--+-------+ 
|1 |x.y.z.w| 
+--+-------+ 

ip_config: 
+--+------+----------+--------+----------+ 
|id|ip_id |t_stamp |archived|config_num| 
+--+------+----------+--------+----------+ 
|1 |1  |1212231313| 1 | 1  | 
|2 |1  |1212299999| 0 | 2  | 
+--+------+----------+--------+----------+ 

ようにする必要があります。理想的には、config_numはconfigテーブルの主キーを指す外部キーです。しかし、構成が異なるタイプで構成されているため、可能ではないようです。これが私の心にあるものです。

config: 
+--+---+----+ 
|id|num|type| 
+--+---+----+ 
|1 | 1 | 1 | 
|2 | 1 | 2 | 
|3 | 2 | 1 | 
|4 | 2 | 2 | 
+--+---+----+ 

entry: 
+--+---------+----+-------------+-------------+-------------+ 
|id|config_id|port|vendor  | product  | version  | 
+--+---------+----+-------------+-------------+-------------+ 
|1 | 1  | 0 | Microsoft | Windows  | XP   | 
|2 | 1  | 0 | Microsoft | Windows  | 7 Home  | 
|3 | 2  | 80 | Apache  | HTTP Server | 2.3.19  | 
|4 | 3  | 0 | Linux  | Linux  | 2.6   | 
|5 | 3  | 0 | Linux  | Linux  | 2.4   | 
|6 | 4  | 22 | OpenSSH  | SSHD  | 4.3p1  | 
+--+---------+----+-------------+-------------+-------------+ 

ただし、（ip_configとconfigテーブルの間に外部キーがないため）一貫性が失われます。 IPは削除されるかもしれませんが、構成は残っています。 要件を満たすためにデザインをどのように変更できますか？

注：タイプ情報（IPまたは設定ごと）は、プログラムの別の部分がどのように期待されるのかという理由から、理想的には別々に管理する必要があります。

Answer 1

私はここですべてを理解しているとは言えないので、この例ではいくつかのアイデアが得られます。

ConfigurationTypeでスタート、これは1- OS; 2- Service ...

Configuration表はすべての可能な（許可）の設定を保持することができます。 ConfigurationTypeNoは、それぞれConfigurationTypeIDの整数（1,2,3 ...）です。したがって、OS（1,2,3 ..）があります。サービス（1,2,3 ...）など。

SystemConfigurationは、各システムのコンフィギュレーション設定の履歴をキャプチャします。 TimeChangedはPKの一部ですが、同じ設定を繰り返すことは可能です。

IP_Allocationは、IP割り当ての履歴を追跡します。