質問3：どんなスキーマが適しているのか？
ここで言うスキーマとは、「データの構造」という意味です。
この質問は「時系列」の話と密接に関連しています。つまり、「時系列にデータを蓄積するには、どんなスキーマが適しているのか？」という質問です。
データの変更履歴を時系列に蓄積する方法として直感的に思いつくのは、トランザクションデータにマスタデータを埋め込むことです。たとえば売上データに商品や会員の属性を埋め込んでしまうという方法で、究極的にはすべてのデータ項目が横一列に並ぶフラットスキーマ（いわゆる「大福帳」と呼ばれるスキーマ）になります。
これに対して「やっぱり第３正規形が最適で、マスタデータの変更履歴はマスタテーブルに蓄積すればよい」という考え方もあります。業務系システムでマスタデータが更新されたら、その変更差分を抽出してデータウェアハウスに挿入すればよい、というわけですが、しかしそのようにすると、データウェアハウスのマスタテーブルには、同じ主キーを持つ複数のデータが存在することになり主キー制約違反になるし、これを許容するとしてもトランザクションデータとのジョインが出来なくなるという問題が発生します。
そこで、さらに別の意見として、有名なディメンジョナルモデル（スタースキーマ）がよいと言う人がいます。時系列の問題に関しては、「緩やかに変化する次元（Slowly Changing Dimension）」としてTypeⅠ～TypeⅢの解決方法が示されているから、これを適用すればよい」という主張です。しかしこの場合、正規形と同じような問題が発生するので、これを改良し、マスタ系のデータはある時点におけるバージョンを個別のテーブルで持つスノーフレークスキーマにした方がよい、と考えられている方もいます。
このように、さまざまな考え方があるので、設計段階で意見がぶつかると、なかなか先へ進みません。このような議論がある中で「最適なスキーマは何？」と問われるわけですから、結論だけ言って済む筈がないことはご理解いただけると思います。
質問4：ETLって何するの？
データウェアハウスを構築する場合、ETLというプロセスが必要になります。業務系システムからデータを抽出（Extract）し、情報系フォーマットへ変換（Transform）した後、データウェアハウスへロード（Load）するという３つのプロセスの頭文字をとってETLと言っています。
このETLに関して質問されるのは、「抽出（E）してロード（L）するのは分かりますが、一体、変換（T）って何をするのか？ 抽出してロードするだけではないのか？」といった処理内容に関することもありますし、「ETLツールを使用する場合、専用のサーバが別途必要になるのか？」といったETLプロセスの物理的配置に関する質問もあります。
また、「ETLツールは変換（T）機能の豊富さが一つの評価基準だということだが、変換プロセスではトランザクションの過去データやマスタデータを参照することがあり、これらはデータウェアハウス内にある。さらに、ETLプロセスはバッチ処理であり、変換プロセスのほとんどはSQLで処理できるわけであるら、E-T-LではなくE-L-Tではないのか？」といった質問も受けたことがあります。
この最後の質問は、ETLが当たり前という既成概念に対する鋭い指摘であり、ソフトウェアの構成にも影響する問題ですから、プロジェクトの計画段階で解決しておく必要があります。
