www.youtube.com 本動画では、平成28年度春期 データベーススペシャリスト試験 午後Ⅰ 問3を取り上げ、保険会社B社の営業支援システムを題材にしたRDBMSセキュリティ設計の見直しを、ビュー（View）とロール（Role）の機能に焦点を当てて解説します。テーマは、顧客の個人情報保護を強化するために、営業部内の組織階層やチーム編成という業務要件を、データベースのアクセス制御へ落とし込む設計力と、SQLおよび権限付与の基本を、与件に即して正確に読み解けるかにあります。午後Ⅰとして本問が狙っているのは、セキュリティを「暗号化」や「ネットワーク対策」といった周辺知識で語るのではなく、RDBMSが提供する標準機能を使って、誰がどのデータにアクセスできるべきかという要件を、再現可能な手順と定義として表現できるかどうかです。採点講評の観点でも、用語の説明や一般論に寄った答案より、ロールの階層付与の意味、ビュー定義における結合種別の選択、パラメータを含むSQLがそのままビュー化できない理由、権限変更の即時性を担保する設計の選択といった、与件の根拠に基づく判断ができたかが得点差になりやすい構造です。 設問1は、ビュー及びロールの設計に関する問題で、営業部門番号B10の配下に営業1課B11、営業2課B12があり、社員（例えばL氏E111、P氏E112など）がそれぞれの課に所属するという階層構造を前提に、営業課別ビューへのSELECT権限をロールへ付与する手順を組み立てさせます。ここでの読解ポイントは、単に「B11が営業1課」「B12が営業2課」という対応付けを当てることではなく、ロールが担うべき役割を、組織階層の“親子関係”として正しくモデル化しているかです。表2のa、b、cを埋める設問では、営業1課ビュー（SQL1）へのSELECT権限を受けるロールがB11、営業2課ビュー（SQL2）へのSELECT権限を受けるロールがB12、そして両課のロールを包含する上位ロールが営業部B10であることを、組織図の読み取りから一貫して導けるかが問われます。ここで失点しやすいのは、ロール名と部門番号の対応は当たっているのに、上位ロールの意義を理解しておらず、B10にB11とB12を束ねる構造が崩れてしまうケースです。上位ロールを設けるのは、営業部全体としての権限管理を簡素化し、課配下の異動や追加があっても管理の変更点を局所化できるからであり、これは権限設計の運用容易性に直結します。 表2のSQL文を正しい順に並べ替える設問は、権限付与の手順が“宣言の依存関係”で決まることを理解しているかを見ています。ロールは存在しなければ付与も参照もできないため、CREATE ROLEが先行します。その後、ロールをユーザへ付与し、さらにロール同士を付与して階層構造を作り、最後にビューへのSELECT権限をロールへ付与する、という流れになります。ここで注意すべき読解ポイントは、「どれが必ず先で、どれは順不同か」を区別することです。B10、B11、B12の作成は互いに依存しないため順不同で実行可能ですが、作成前に付与はできません。同様に、ロール階層の付与とユーザへの付与は、対象のロールが存在する限り、相互の実行順に厳密な一意解があるとは限りません。一方で、ビューに対するSELECT権限をロールに付与する操作は、付与対象のロールが存在し、かつ権限付与対象のビューが存在することが前提になります。採点講評が意識しているのは、単に暗記した順序を並べるのではなく、DDLと権限付与が持つ前提条件を理解し、依存関係に基づいて整然と並べられているかです。ここを外すと、設問1の後半で示されるロール設計が、運用として実行不可能な手順になってしまうため、答案全体の説得力が落ちます。 設問2はビューの設計変更がテーマで、照会1と照会2に関するSQLの穴埋めや、ビューにできるSQLとできないSQLの見極めを問います。SQL3で過去に登録した訪問予定のうち、その社員が訪問しなかった顧客を抽出する場面では、訪問予定が存在しても訪問実績がない行を残す必要があるため、結合種別の選択が本質になります。顧客テーブルKと訪問予定テーブルHYの結合は、予定がある顧客を対象にするという文脈で内部結合が自然ですが、その後、訪問予定を基準に訪問実績HJが存在しない行を拾うには、左外部結合が必要になります。午後Ⅰの読解ポイントは、「存在しないものを抽出する」要件が出たときに、外部結合の方向を誤らないことです。訪問予定があって訪問実績がないものを拾うなら、基準にすべきは訪問予定であり、訪問実績を外部結合の右側に置いてNULLを作りにいく構造になります。ここを取り違えると、欲しい“未訪問”が結果に残らないという致命的な誤りになります。 SQL4に関して、年初からの訪問回数がN回以上の社員を抽出する照会2をビュー化する際に問題となるのは、HAVING句に含まれる動的パラメータです。ビュー定義は固定的なSELECT文として登録されるため、実行時に外から与える値で意味が変わるプレースホルダを、そのまま埋め込めないという制約が論点になります。ここで合否を分けるのは、単に「?がだめ」と答えるだけではなく、なぜそれがビューの定義として不適切なのかを、ビューが“再利用可能な固定定義”であるという性質から説明できるかです。この理解ができると、次のSQL5でどのように解決するかが自然に導けます。つまり、集計結果そのものはビューとして固定化し、しきい値Nによる絞り込みはビューを参照する側のSQLでWHERE句として与える、という二段構えです。SQL5の空欄に入るべき条件が訪問回数＞=?となるのは、ビューが返す列として訪問回数が定義されているからであり、設計変更の意図とSQLの役割分担を理解していれば迷いにくいポイントです。採点講評が評価するのは、ビューにできない要素を排除して“ビューでできる部分”と“利用側でやる部分”に分割する発想であり、これは実務のデータベース設計でも頻繁に使う解決パターンです。 設問3はセキュリティ要件の強化を受けた設計選択が中心で、課単位の静的な権限管理から、チーム単位のより細かなアクセス制御へ移るときに、ロール中心で対応する案と、チームメンバテーブルとビュー条件で対応する案の比較が問われます。本問の読解ポイントは、セキュリティ要件①が「チームの社員は、当該チームが担当する顧客の個人情報にアクセスできる」という形に変更されたことで、アクセス権限の変更が人の異動や担当終了に応じて頻繁かつ即時に発生し得る、という運用面の要求が増したことを正確に把握することです。対応案Bが有利になる理由として、課長がチームメンバテーブルの担当終了日を更新すればアクセス範囲を直ちに制限できる点が挙げられます。これに対し、ロールの剥奪を前提とする案では、運用上DBAの作業や手続きを要し、即時反映が難しい可能性があるため、要件と合致しにくくなります。採点講評で差が出るのは、どちらが「セキュア」かという抽象論ではなく、要件が求める即時性と運用主体を読み取り、設計上の制御点がどこに置かれているかを説明できるかです。 また、ビューSQL6のようにCURRENT_USERを用いてログイン中の社員を判別し、その社員が現在担当しているチームの顧客にだけアクセスを限定する設計は、静的な権限付与と動的な行レベル制御を組み合わせる発想として重要です。午後Ⅰとしては、CURRENT_USERが何を表すのか、そしてそれがビューのWHERE条件に入ることで“誰が見ているか”に応じて結果が変わるという性質を、セキュリティ機能として理解しているかが問われています。さらに、チームメンバテーブルの主キー設計について、社員がチームを離脱・復帰し得る、担当期間を管理する必要がある、といった業務要件を踏まえると、単純に部門番号＋チーム番号＋社員番号だけでは一意にならず、担当開始日まで含めたキーが必要になるという読み取りが重要になります。この部分は採点講評でも漏れが指摘されやすい論点で、テーブル構造の“見た目”だけでキーを決めるのではなく、履歴管理が必要な業務であることを文章から拾い、主キーに時間軸を入れる設計へ到達できるかが合否を分けます。 本動画では、平成28年度春期データベーススペシャリスト試験 午後Ⅰ 問3の各設問を通じて、ビューとロールを使ったアクセス制御を、実務で通用する設計判断として理解できるように、読み取りの順序を明確にして解説します。具体的には、組織階層をロール階層へ写像する際の依存関係の捉え方、外部結合の方向と未存在データ抽出の関係、ビュー定義に含められる要素と含められない要素の境界、そして要件変更に強い設計として、テーブル更新による即時制御とCURRENT_USERによる動的制御をどう組み合わせるかを整理します。最後まで視聴する意義は、セキュリティを概念だけで語るのではなく、与件に基づく制約、手順、SQL、キー設計として具体化する力を身に付けられる点にあります。午後Ⅰで安定して得点するための“読解の型”を獲得し、同種のデータベースセキュリティ問題に対しても、一般論ではなく根拠ある設計として答案を組み立てられるようになることが、本動画の到達目標です。
