top 24 data modeling interview questions with detailed answers
今後の面接の準備に役立つ、最もよくあるデータモデリング面接の質問と回答のリスト：
ここでは、いくつかの有名なIT MNCでの面接のやりとりでの自分の経験に基づいて、データモデリングの面接の質問と詳細な回答をいくつか共有します。
以下の質問と回答は、データモデリングに直面したり、インタビューを受けたりする機会があれば、非常に役立ちます。
最もよくあるデータモデリングのインタビューの質問
はじめましょう！
Q＃1）データモデリングで何を理解していますか？
回答： データモデリング は、エンティティが互いにどのように関連しているかを示す図式表現です。これは、データベース設計に向けた最初のステップです。最初に概念モデルを作成し、次に論理モデルを作成し、最後に物理モデルに移動します。
通常、データモデルは、ソフトウェア開発ライフサイクルのデータ分析および設計フェーズで作成されます。
Q＃2） さまざまなデータモデルについての理解を説明してください。
回答： データモデルには、概念、論理、物理の3種類があります。複雑さと詳細のレベルは、概念から論理、そして物理データモデルへと増加します。
概念モデルは非常に基本的な高レベルの設計を示していますが、物理データモデルは非常に詳細な設計ビューを示しています。
- 概念モデル エンティティ名とエンティティの関係を表すだけです。この記事の後半に示されている図1は、概念モデルを示しています。
- 論理モデル 各エンティティのエンティティ名、エンティティの関係、属性、主キー、および外部キーが表示されます。この記事の質問＃4の中に示されている図2は、論理モデルを示しています。
- 物理データモデル 主キー、外部キー、テーブル名、列名、および列データ型が表示されます。このビューは、モデルが実際にデータベースに実装される方法を実際に詳しく説明しています。
Q＃3） これまでに取り組んできたプロジェクトに関して、データモデリングの経験に光を当てますか？
注意： これは、私のデータモデリングインタビューの1つで最初の質問でした。したがって、面接のディスカッションに入る前に、データモデリングが作業した割り当てにどのように適合するかを非常に明確に把握しておく必要があります。
回答： 私は、インターフェースが組み込まれている健康保険プロバイダー会社のプロジェクトに取り組んできました。 コンピューティング これは、ファセットデータベースからフェッチされたデータを変換および処理し、有用な情報をベンダーに送信します。
注意： ファセットは、ヘルスケア業界のすべての情報を管理するためのエンドツーエンドのソリューションです。私のプロジェクトのファセットデータベースは、SQL Server2012で作成されました。
互いにリンクされたさまざまなエンティティがありました。これらのエンティティは、加入者、メンバー、医療提供者、請求、請求、登録、グループ、適格性、プラン/製品、コミッション、キャピテーションなどでした。
以下は、プロジェクトが高レベルでどのように見えるかを示す概念データモデルです。
図1：
各データエンティティには、独自のデータ属性があります。 例えば、 プロバイダーのデータ属性はプロバイダーID番号になり、メンバーシップのいくつかのデータ属性はサブスクライバーID、メンバーIDになり、クレームのデータ属性の1つはクレームIDになり、各ヘルスケア製品またはプランには一意の製品IDがあります。など。
Q＃4）データモデリングのさまざまな設計スキーマは何ですか？で説明する例？
回答： データモデリングには2種類のスキーマがあります
- スタースケジュール
- スノーフレークスキーマ
ここでは、これらのスキーマを1つずつ説明します。
最も単純なスキーマはスタースキーマであり、中央にファクトテーブルがあり、その周りの複数のディメンションテーブルを参照しています。すべてのディメンションテーブルはファクトテーブルに接続されています。すべてのディメンションテーブルの主キーは、ファクトテーブルの外部キーとして機能します。
ザ・ IS図 このスキーマの（図2を参照）は星の形に似ているため、このスキーマはスタースキーマと呼ばれます。
図2：
スタースキーマは非常にシンプルで柔軟性があり、非正規化された形式になっています。
スノーフレークスキーマでは、正規化のレベルが高くなります。ここのファクトテーブルは、スタースキーマと同じままです。ただし、ディメンションテーブルは正規化されています。ディメンションテーブルが複数のレイヤーになっているため、スノーフレークのように見えるため、スノーフレークスキーマと呼ばれます。
Javaインタビューコードの質問と回答
図3：
Q＃5）プロジェクトでどのスキームを使用しましたか？その理由は何ですか？
Q＃6）スターとスノーフレークのどちらのスキーマが優れていますか？
回答：（Q＃5と6の組み合わせ）： スキーマの選択は、常にプロジェクトの要件とシナリオによって異なります。
スタースキーマは非正規化された形式であるため、クエリに必要な結合は少なくなります。クエリは単純で、スタースキーマでより高速に実行されます。スノーフレークスキーマについては、正規化された形式であるため、スタースキーマと比較して多数の結合が必要になり、クエリが複雑になり、実行がスタースキーマよりも遅くなります。
これら2つのスキーマのもう1つの重要な違いは、スノーフレークスキーマには冗長データが含まれていないため、保守が容易なことです。逆に、スタースキーマは冗長性が高いため、維持が困難です。
さて、あなたのプロジェクトのためにどれを選ぶべきですか？プロジェクトの目的がより多くのディメンション分析を行うことである場合は、スノーフレークスキーマを使用する必要があります。 例えば、 あなたがそれを見つける必要がある場合 「現在アクティブな特定のプランに関連付けられているサブスクライバーは何人ですか？」 –スノーフレークモデルを使用します。
プロジェクトの目的がより多くのメトリック分析を行うことである場合は、スタースキーマを使用する必要があります。 例えば、 あなたがそれを見つける必要がある場合 「特定の加入者に支払われる請求額はいくらですか？」 –スタースキーマを使用します。
私のプロジェクトでは、複数のディメンションにわたって分析を行い、ビジネスの要約レポートを生成する必要があるため、スノーフレークスキーマを使用しました。スノーフレークスキーマを使用するもう1つの理由は、メモリ消費量が少ないことです。
Q＃7）次元と属性で何を理解していますか？
回答： ディメンションは定性的なデータを表します。 例えば、 計画、製品、クラスはすべて次元です。
ディメンションテーブルには、説明属性またはテキスト属性が含まれています。 例えば、 製品カテゴリと製品名は、製品ディメンションの属性です。
Q＃8）ファクトとファクトテーブルとは何ですか？
回答： 事実は定量的データを表しています。
例えば、 正味支払額は事実です。ファクトテーブルには、関連するディメンションテーブルの数値データと外部キーが含まれています。ファクトテーブルの例は、上記の図2から見ることができます。
Q＃9）あなたが遭遇したさまざまなタイプの次元は何ですか？それぞれを例を挙げて詳しく説明しますか？
回答： 通常、5種類の寸法があります。
a）適合寸法 ：さまざまな領域の一部として使用されるディメンションは、適合ディメンションと呼ばれます。単一のデータベース内のさまざまなファクトテーブルで、または多数のデータマート/ウェアハウスで利用される可能性があります。
例えば、 サブスクライバーディメンションが2つのファクトテーブル（請求と請求）に接続されている場合、サブスクライバーディメンションは適合ディメンションとして扱われます。
b）ジャンク寸法 ：これは、ファクトテーブルまたは現在のディメンションテーブルのいずれにも配置されていない属性で構成されるディメンションテーブルです。一般的に 、 これらはフラグやインジケーターのようなプロパティです。
シェルスクリプトでwhileループを実行する
例えば、 これは、「Y」または「N」として設定されたメンバー適格性フラグ、またはtrue / falseとして設定されたその他のインジケーター、特定のコメントなどです。このようなインジケーター属性をすべてファクトテーブルに保持すると、サイズが大きくなります。そう 、 このようなすべての属性を組み合わせて、すべてのインジケーター値の可能な組み合わせを使用して、一意のジャンクIDを持つジャンクディメンションと呼ばれる単一のディメンションテーブルに配置します。
c）ロールプレイングの側面 ：これらは、同じデータベースで複数の目的に使用されるディメンションです。
例えば、 日付ディメンションは、「請求日」、「請求日」、または「計画期間日」に使用できます。そう 、 このようなディメンションは、ロールプレイングディメンションと呼ばれます。 Dateディメンションの主キーは、ファクトテーブル内の複数の外部キーに関連付けられます。
d）ゆっくりと変化する次元（SCD）： これらは、すべての次元の中で最も重要です。これらは、属性値が時間とともに変化するディメンションです。以下は、さまざまなタイプのSCDです。
- タイプ0： これらは、属性値が時間とともに安定している次元です。 例えば、 加入者のDOBは、時間に関係なく常に同じままであるため、タイプ0のSCDです。
- タイプ1： これらは、属性の以前の値が現在の値に置き換えられるディメンションです。タイプ1ディメンションでは履歴は保持されません。 例えば、 サブスクライバーのアドレス（ビジネスがサブスクライバーの現在のアドレスのみを保持する必要がある場合）は、タイプ1ディメンションにすることができます。
- タイプ2： これらは、無制限の履歴が保存される次元です。 例えば、 サブスクライバーのアドレス（ビジネスがサブスクライバーの以前のすべてのアドレスの記録を保持する必要がある場合）。この場合、サブスクライバーの複数の行が、異なるアドレスでテーブルに挿入されます。現在の住所を識別する列がいくつかあります。 例えば、 「開始日」と「終了日」。 「終了日」の値が空白になる行には、サブスクライバーの現在のアドレスが含まれ、他のすべての行には、サブスクライバーの以前のアドレスが含まれます。
- タイプ3： これらは、限られた履歴が保持されるタイプのディメンションです。また、履歴を維持するために追加の列を使用します。 例えば、 加入者の住所（企業が現在の住所と以前の住所を1つだけ記録する必要がある場合）。この場合、「address」列を「currentaddress」と「previousaddress」の2つの異なる列に分解できます。したがって、複数の行を使用する代わりに、サブスクライバーの現在のアドレスと以前のアドレスを表示する行を1つだけ表示します。
- タイプ4： このタイプのディメンションでは、履歴データは別のテーブルに保存されます。メインディメンションテーブルは、現在のデータのみを保持します。 例えば、 メインディメンションテーブルには、現在のアドレスを保持するサブスクライバーごとに1つの行のみがあります。サブスクライバーの他のすべての以前のアドレスは、別の履歴テーブルに保持されます。このタイプの寸法はほとんど使用されていません。
e）縮退した寸法： 縮退したディメンションは、ファクトではないが、ファクトテーブルに主キーとして表示されるディメンションです。独自のディメンションテーブルはありません。これを単一の属性ディメンションテーブルと呼ぶこともできます。
だが 、 ディメンションテーブルに個別に保持して追加の結合を配置する代わりに、この属性をファクトテーブルにキーとして直接配置します。独自のディメンションテーブルがないため、ファクトテーブルで外部キーとして機能することはできません。
Q＃10）事実のない事実についてあなたの考えを教えてください。そして、なぜそれを使用するのですか？
回答： ファクトレスファクトテーブルは、ファクトメジャーを含まないファクトテーブルです。寸法キーのみが含まれています。
時には、事実のないファクトテーブルが必要なビジネスで特定の状況が発生する可能性があります。
例えば、 従業員の出席記録システムを維持しているとすると、3つのキーを持つ事実のないファクトテーブルを持つことができます。
| 従業員ID |
| Department_ID |
| Time_ID |
上記の表にはメジャーが含まれていないことがわかります。さて、以下の質問に答えたい場合は、2つの別々のファクトテーブルを用意するのではなく、上記の単一のファクトレスファクトテーブルを使用して簡単に行うことができます。
「特定の部門の何人の従業員が特定の日に出席しましたか？」
したがって、事実のないファクトテーブルは、設計に柔軟性を提供します。
Q＃11）OLTPとOLAPを区別しますか？
回答： OLTPは オンライントランザクション処理システム ＆OLAPは オンライン分析処理システム 。 OLTPは、ビジネスのトランザクションデータを維持し、一般的に高度に正規化されています。それどころか、OLAPは分析とレポートの目的であり、非正規化された形式です。
OLAPとOLTPのこの違いにより、スキーマの設計を選択する方法も提供されます。システムがOLTPの場合は、スタースキーマ設計を使用する必要があり、システムがOLAPの場合は、スノーフレークスキーマを使用する必要があります。
Q＃12）データマートで何を理解していますか？
回答： データマートは、ほとんどの場合、単独の事業部門を対象としています。それらは個々の部門向けに設計されています。
例えば、 私は以前、財務、報告、営業など、さまざまな部門を持つ健康保険会社で働いていました。
これらすべての部門に関連する情報を保持するデータウェアハウスがあり、このデータウェアハウスの上に構築されたデータマートはほとんどありません。これらのデータマートは各部門に固有のものでした。簡単に言うと、DataMartはデータウェアハウスのサブセットであると言えます。
Q＃13）さまざまな種類の対策は何ですか？
回答： 対策には3つのタイプがあります。
- 非加法的な対策
- 半加法的な対策
- 付加的な対策
非加法メジャーとは、その上に集計関数を適用できないメジャーです。 例えば、 比率またはパーセンテージの列。 Y / Nなどの値を保持するファクトテーブルに存在するフラグまたはインジケーター列は非加算的な測定値です。
半加法メジャーは、その上にいくつかの（すべてではない）集計関数を適用できるメジャーです。 例えば、 手数料率または口座残高。
加算メジャーは、その上にすべての集計関数を適用できるメジャーです。 例えば、 購入したユニット。
Q＃14）サロゲートキーとは何ですか？主キーとどう違うのですか？
回答： サロゲートキーは、主キーとして機能できる一意の識別子またはシステム生成のシーケンス番号キーです。これは、列または列の組み合わせにすることができます。主キーとは異なり、既存のアプリケーションデータフィールドからは取得されません。
Q＃15）これは、すべてのデータベースが3NFである必要があるということですか？
回答： データベースが3NFである必要はありません。しかしながら 、 データの保守が簡単で、冗長性が低く、アクセスが効率的であることが目的の場合は、非正規化データベースを使用する必要があります。
Q＃16）再帰的な関係のシナリオに出くわしたことがありますか？はいの場合、どのように処理しましたか？
回答： エンティティがそれ自体に関連している場合、再帰的な関係が発生します。はい、私はそのようなシナリオに出くわしました。
ヘルスケアの領域について言えば、ヘルスケア提供者（たとえば医師）が他のヘルスケア提供者の患者である可能性があります。なぜなら 、 医者自身が病気になり、手術が必要な場合、彼は外科的治療を受けるために他の医者を訪ねなければなりません。
そう 、 この場合、エンティティ–ヘルスケアプロバイダーはそれ自体に関連しています。健康保険会社の番号の外部キーは、各メンバー（患者）の記録に提示する必要があります。
Q＃17）データモデリング中に発生する一般的な間違いをいくつか挙げてください。
回答： データモデリング中に発生する一般的な間違いは次のとおりです。
- 大規模なデータモデルの構築 ：大規模なデータモデルは、より多くの設計上の欠陥があるようです。データモデルを200テーブル以下に制限するようにしてください。
- 目的の欠如 ：ビジネスソリューションの目的がわからない場合は、誤ったデータモデルを思い付く可能性があります。したがって、適切なデータモデルを考案するには、ビジネス目的を明確にすることが非常に重要です。
- 代理キーの不適切な使用 ：代理キーを不必要に使用しないでください。自然キーが主キーの目的を果たせない場合にのみ、代理キーを使用してください。
- 不必要な非正規化 ：非正規化は維持が困難な冗長データを作成するため、明確なビジネス上の理由がない限り、非正規化しないでください。
Q＃18）単一の親テーブルから作成できる子テーブルの数はいくつですか？
回答： 単一の親テーブルから作成できる子テーブルの数は、非キーである親テーブルのフィールド/列の数と同じです。
Q＃19）従業員の健康の詳細は、医療提供者によって雇用主から隠されています。これはどのレベルのデータ隠蔽ですか？概念的、物理的、または外部？
回答： これは、外部レベルのデータ隠蔽のシナリオです。
Q＃20）ファクトテーブルとディメンションテーブルの形式は何ですか？
回答： 通常、ファクトテーブルは正規化された形式であり、ディメンションテーブルは非正規化された形式です。
Q＃21）ヘルスケアドメインプロジェクトで概念モデルを考え出すために必要な詳細は何ですか？
回答： ヘルスケアプロジェクトの場合、基本的な概念モデルを設計するには、以下の詳細で十分です。
- ヘルスケアプランと製品のさまざまなカテゴリ。
- サブスクリプションのタイプ（グループまたは個人）。
- 医療提供者のセット。
- 請求および請求プロセスの概要。
Q＃22）トリッキーなもの：一意の制約が列に適用されている場合、2つのnullを列に挿入しようとすると、エラーがスローされますか？
回答： いいえ、この場合、null値は別のnull値と等しくないため、エラーはスローされません。したがって、エラーなしで複数のnullが列に挿入されます。
Q＃23）サブタイプとスーパータイプのエンティティの例を引用できますか？
回答： はい、車、車、自転車、エコノミーカー、ファミリーカー、スポーツカーなどのさまざまなエンティティがあるとします。
ここで、車両はスーパータイプのエンティティです。車と自転車はそのサブタイプのエンティティです。さらに、エコノミーカー、スポーツカー、ファミリーカーは、スーパータイプのエンティティカーのサブタイプエンティティです。
スーパータイプのエンティティは、より高いレベルにあるエンティティです。サブタイプエンティティは、特定の特性に基づいてグループ化されたエンティティです。 例えば、 すべてのバイクは二輪車で、すべての車は四輪車です。また、どちらも車両であるため、スーパータイプのエンティティは「車両」です。
Q＃24）メタデータの重要性は何ですか？
回答： メタデータはデータに関するデータです。システムに実際に保存されているデータの種類、その目的、対象者を示します。
結論
- の実用的な理解 データモデリング データモデリングのインタビューをクラックするには、概念とそれがあなたが行った割り当てにどのように適合するかが非常に必要です。
- で最もよく聞かれるトピック データモデリング インタビューは、さまざまなタイプのデータモデル、スキーマのタイプ、ディメンションのタイプ、および正規化です。
- シナリオベースの質問にも十分に備えてください。
インタビュアーに質問に答えるときはいつでも、例を通してアイデアを説明することをお勧めします。これは、あなたが実際にその分野に取り組み、概念の核心を非常によく理解していることを示しています。
セレンウェブドライバーのラジオボタンを選択する方法
ではごきげんよう！！