例：グループに所属するユーザーを列挙する
以下の様なテーブルでユーザーとユーザーが所属するグループを管理している場合。

テーブル名：test_user（ユーザーマスタ）

テーブル名：test_group（グループマスタ）

テーブル名；group_user（グループとユーザーの連結情報）

グループに所属するユーザーを取得しようと考える場合、
以下の様なSQLになるかと思います。

 SELECT A.group_code, A.group_name, C.user_name
 FROM test_group A
 INNER JOIN group_user B ON A.group_code = B.group_code
 INNER JOIN test_user C ON B.user_code = C.user_code
 ORDER BY A.group_code, C.user_code
 

結果はこの様になります。

これはこれでいいのですが、
ユーザー名を羅列して、１フィールドの値として扱いたい場合、
ストアドプロシージャでカーソルを利用し、
user_nameを結合する必要が有ります。
もしくは、プログラムでこの結果を取得した後、
ループ処理を行うなど、何かしらの処理が必要になります。

もし、結合した結果を取得できれば、
上記の様な処理を記述する必要もなくなります。

SQLServerには結果をXML形式で取得する、
FOR XML句という記述形式が有ります。
FOR XML (SQL Server)
上記の例を使用し、以下のSQLを実行します。

 SELECT A.group_code, A.group_name,
 (SELECT '・' + D.user_name
 FROM test_group B
 INNER JOIN group_user C
 ON B.group_code = C.group_code
 INNER JOIN test_user D
 ON C.user_code = D.user_code
 WHERE B.group_code = A.group_code
 ORDER BY D.user_code
 FOR XML PATH(''),TYPE).value('.', 'VARCHAR(MAX)') AS group_user_name
 FROM test_group as A
 

結果はこの様になります。

普通の結合では2レコードになるGroupAのユーザーを
1レコードで取得しています。

FOR XML句を使い、XML形式で出力したSQLの結果に対して、
value()メソッドを使い、Varchar型で取得し、
サブクエリとして呼び出しております。

サブクエリでの処理について解説します。
まずは、SELECT ～ ORDER BY D.user_codeまでは普通のSQLです。
SELECT句で「’・’」とuser_nameを結合しており、
WHEREでサブクエリ内のgroup_codeを指定しておりますので、
出力文字列はA.group_code=’G001’のときは、「・アイチャン」「・ワークン」
A.group_code=’G002’のときは「・アイコック 太郎」となります。

通常のSQLで処理し、行で取得した際には、「・アイチャン」「・ワークン」は
2レコードで出力されますが、
FOR XML句を使用しておりますので、XML形式で出力されます。
PATH(”)として、属性を付けておりませんので、
出力内容はこの様になります。

もし、PATH(‘name’)と属性名を与えた場合、出力されるXMLはこの様になります。

（ちなみに、属性名を付けていても、上記のSQLの結果は変わらないので、属性名を付ける付けないはお好みで良いかと思います）

FOR XML句で出力した値はXML形式で出力されるため、他のフィールドとは扱いが異なりますので、
value()メソッドを使い、通常のSQL型に変換します。
サブクエリを表す()の後に「.value(‘.’, ‘VARCHAR(MAX)’)」と記述しております。
value()メソッドの第一引数はXQuery式で、第二引数はSQL型となります。

第一引数の「’.’」はXQuery式「self::node()」の省略形、
第二引数では、ユーザー名を扱い、出力文字数の制限をしたくないので、
VARCHAR(MAX)としており、
出力されたXML形式のデータからvalue値を取得するため、
属性が指定されていようが関係なく、「・アイチャン・ワークン」といったvalue値を取得し、
第二引数で指定されたVARCHARとして、SQL型の結果を返します。
value() メソッド (xml データ型)

こうすることで、複数レコードを結合したデータを単一のレコードとして扱う事が可能になります。

ユーザー名をカンマ区切りで表示したい場合なんかは、
サブクエリのSELECT句を「SELECT user_name + ‘,’」と記述することで
可能となります。
ただし、文字列の最後にカンマがついている状態なので、
SUBSTRING()メソッドを使い、最後の文字を除外するなどの一手間は必要になります。

サブクエリをスカラー値関数として作成し、
抽出条件を引数として指定できるようにしておけば、
上記のカンマ区切りを実現するためのSUBSTRING()メソッドも書きやすくなるのではないかと思います。

文章で書くと難しくなりがちですが、
文字列を結合する程度の事であれば、簡単にできるため、
使う機会が有れば、試してみてはいかがでしょうか。

dn: cn=user2,ou=users,dc=icoc,dc=co,dc=jp
cn: user2
objectClass: organizationalRole
objectClass: simpleSecurityObject
userPassword: user2Password

このような形式になります。
dnからuserPasswordまでで1ユーザーの情報となっています。

ある程度の数のユーザーを一括で登録したい場合、
CSVは横方向に情報を持つため、EXCELなどを使用することで
複数ユーザーに対して、一括での追加、編集が容易に行えますが、
LDIFでは縦方向に情報を持つので、複数ユーザーに対しての一括追加、編集は
CSVに比べると、容易には行えません。

これを考慮すると、
データの作成はEXCELなどを用いて作成し、
インポートを行う時にLDIFに変換できれば、
大量のユーザーを扱う際でも手間ではなくなります。

そこでCSVをLDIFに変換するツールは無いものかと探したところ、
csv2ldif2というスクリプトがありました。
http://sourceforge.net/projects/csv2ldif2/

上記URLから「csv2ldif2-1.1.tar.gz」をダウンロードします。
圧縮形式はtar.gzなので、Windowsで使用する場合、
解凍ソフトを用いる必要があります。

ファイル解凍後、フォルダが作成されますので任意の位置に配置します。
コマンドラインからは以下の様に実行します。

cd フォルダの配置場所
perl csv2ldif2.pl "ou=users,dc=icoc,dc=co,dc=jp" < tsuika.csv > tsuika.ldif


perlで書かれているため、perlを宣言後、スクリプトファイルを指定します。
ファイル名の後、LDAP上でユーザーを配置するディレクトリを指定します。
上記の”ou=users,dc=icoc,dc=ac,dc=jp”という箇所です。
その後、変換元のファイル名を記述します。
このとき必ず<>で囲む必要が有ります。
最後に変換後のファイル名を記述し、実行すると、変換が行われます。

例えば、以下の内容を持つCSVを変換すると、

cn,objectClass,objectClass,userPassword
user1,organizationalRole,simpleSecurityObject,user1Password


dn: cn=user1,ou=users,dc=icoc,dc=co,dc=jp
cn: user1
objectClass: organizationalRole
objectClass: simpleSecurityObject
userPassword: user1Password


このように変換されます。
変換したLDIFをLDAPへインポートすれば、ユーザーの一括登録が行えます。

この設定を行う際の注意することがあり、
スケジュール実行するexeが外部ファイル（例えばログファイルなど）に書き込みを行う場合や、
フォルダ内にファイルを生成する場合には、
SQLServerエージェントが対象となるファイルやフォルダに対して、
アクセス許可を有する必要が有ります。

アクセス許可の編集は、対象のファイルやフォルダのプロパティで行えますが、
その際、必要になる情報としてユーザー名が必要になります

通常のユーザーであれば、ユーザー名が分からなくても、
アクセス許可の編集画面でユーザーの検索が可能なので、問題は有りませんが、
SQLServerエージェントが使用するログオンユーザーは上記の検索では表示されません。

では、どの様にSQLServerエージェントのユーザーを確認するのかというと、
「SQLServer構成マネージャー」を使用します。

これはSQLServer構成マネージャーを起動し、左側のペインからSQLServerのサービスを選択した画面です。
右側のペインにSQLServerが使用しているサービスが表示されています。
この最下行に「SQL Serve エージェント（MSSQLSERVER)」があり、その隣の列にログオンという列が有ります。
このログオン列に記載されている内容がサービスが使用するログオンアカウントであり、
アクセス許可で使用するユーザー名となります

調べたログオンアカウントをアクセス許可のユーザー検索で名前の確認をすることで、
アクセス許可にユーザーの追加が可能になります

追加後は、他のアカウント同様に権限の設定を行います。

あるDataTableから必要なフィールドのみを選択し、
新規のDataTableを作る必要が有りました。

そこで、今回は以下の様に対応しました。

元となるDataTable：table1
必要なフィールドのみを持つ新規DataTable：table2
必要なフィールドのインデックス：0,1,3,4,7

// 必要なフィールドの列名を配列化します。
string[] requiredColumns = {dt.Columns[0].ToString(),
                            dt.Columns[1].ToString(),
                            dt.Columns[3].ToString(),
                            dt.Columns[4].ToString(),
                            dt.Columns[5].ToString(),
                           };

// 元のテーブルから必要なフィールドのみを抽出して、テーブルを新規作成します。
System.Data.DataTable table2 = table1.DefaultView.ToTable(true, requiredColumns);

ToTableの最初の引数は、重複する行を含むかどうかをBool値で指定します。
Trueなら重複しない行のみ格納され、Falseでは重複する行も格納されます。
二つ目の引数は、抽出する列名を指定します。
ここでは、事前に配列化しておいた変数をセットしました。

場合によっては、新規作成したテーブルの構造と値をそのまま別のテーブルで使用したい場合には、
以下の様に行います。

// table2の構造と値をtable3へコピーします。
System.Data.DataTable table3 = table2.Copy();

//table2の構造のみをtable4へコピーします。
System.Data.DataTable table4 = table2.Clone();

Cloneは構造のみをコピーするので、
table2と同じ構造を持ち、値は異なる、といったデータの保持が可能になります。

また、元のテーブルと同じ構造を持ち、元のテーブル特定行のみを移したい場合、
ImportRow()メソッドを使用します。

System.Data.DataTable table4 = table2.Clone();
table4.ImportRow(table2.Rows[0]);

とすることで、table2の1行目のデータをtable4へインポートできます。

稼働中のシステムを改修し、本番環境へ反映する際に、
プログラムの入替のみではなく、
データベースの更新作業が必要なことがあります。

あまり考えたくありませんが、
例えば、テーブルやビューにフィールドの追加や
新しく作成したストアドプロシージャやユーザー関数を追加などです。

確実なのは、作業リストを作成し、
改修した機能について、どのテーブル・ビューなどが改修されたか記録を取ることでしょう。

ただし、改修に時間が掛かったり、
複数の機能改修をまとめて反映する際には、
記録漏れが出ることも有ります。

これを回避するため、
DB内のテーブル・ビュー・ユーザー関数を更新された順に取得したいと思います。

該当のDBに対し、以下のSQLを実行します。

SELECT name, modify_date
FROM sys.objects
WHERE type in ('V', 'U', 'FN', 'P')
ORDER BY modify_date desc

sys.objects はデータベース内のオブジェクトを管理しているテーブルです。

SELECT句にはオブジェクト名(name), 更新日(modify_date)を指定します。
WHERE句には抽出する条件を指定します。
今回は、新しく更新された順に、
テーブル名・ビュー名・関数名・ストアドプロシージャが取得できればよいので、
U：テーブル(ユーザー定義)
V：ビュー
FN：スカラー関数
P：ストアドプロシージャ
の4文字をtypeに指定します。
ORDER BYにて、変更日の降順に出力すれば、
変更日が新しい順に更新したテーブル等が確認できる、ということになります。

typeはこれ以外にもありますが、
改修時に変更の頻度が高いのは上記の4つかな、と思いましたので、
この様に記述しています。

sys.objectsについて、詳しくはこちらに記述が有ります。
sys.objects（Transact-SQL）

●各レベルの簡単な構成とメリット・デメリットについて。

・RAID0
複数台のHDDにデータを分散して書き込む。
RAID後の容量はHDDの最低容量 × HDD数となります。
300GBと500GBのHDDをRAID0で構成すると、
300GB × 2台 = 600GBとなります。
500GBのHDDで未使用領域である200GB分は使用不可となります。
（以降のRAIDレベルでも同様）

メリット
・HDDの数が増えるに従い、アクセス速度が上がります。
デメリット
・冗長化されない
・HDDが1台でも故障すれば、データは全て喪失します。

・RAID1
複数台(偶数)のHDDに同時に同じ内容のデータを書き込む。
RAID後の容量はHDDの最低容量 × HDD数 ÷ 2 となります。
300GBと500GBのHDDをRAID1で構成すると、
300GB × 2台 ÷ 2 = 300GBとなります。

メリット
・故障がHDD数-1台であれば、正常なHDDと入れ替えることで、復旧が可能。
デメリット
・ディスク容量は実容量の半分となる。

・RAID5
複数台のHDDにデータを分散して書き込み、その内1台には、誤り訂正用のデータを書き込む。
この訂正用のデータが結果として、1ドライブ分のデータ容量を使用するため、
RAID後の容量はHDDの最低容量 × (HDD数-1) となります。
300GBと500GB（2台）のHDDをRAID5で構成すると、
300GB × (3台-1）= 600GBとなります。

メリット
・RAID0に比べて障害性が高く、RAID1に比べて容量が多い。
デメリット
・読込は早いが、書込は遅い
・HDDが1台壊れても使用できるが、信頼性は低下し、アクセス速度も低下する。

以上、使用頻度が高い3レベルについて簡単に触れました。

RAIDは便利な仕組みですが、目的に沿った選択をしないと、デメリットに悩まされることにもなります。

他にも、RAID6といった今回記載していないレベルや、
RAID0とRAID1を組み合わせたRAID0 + 1やRAID1+0 なども存在しますが、
そちらについては、また機会があれば。

前回はRAIDを提供するハードウェアとソフトウェアについて、
記しましたので、
今回は、RAID構成を話す予定でしたが、
その前に、RAIDにより提供される機能について話を行いたいと思います。

RAIDにより提供される機能は
大きく二つあります。

1つはHDD故障への耐性です。
通常、HDDが1台しかないと、
HDDの故障とデータの喪失はほぼ同意ですが、
HDDを複数配置して冗長化することにより
もしHDDの一つに故障が発生した場合でも、
残りのHDDに故障が無ければ、データの損失は無く、
故障したHDDを正常なHDDに交換することで、
故障したHDDに配置されていたデータを復元できます。
またRAIDコントローラによっては、
サーバやNASの電源を入れたまま、HDDを交換できる機能である
ホットスワップを有する物もあります。
また、これとは別に、予備のHDDを機器に接続しておいて、
故障が発生した際には、予備のHDDを使用する機能を
ホットスペアといいます。

もう一つはデータ処理の高速化です。
ファイルが一つあったとして、
これがHDDに保存される際には、
いくつものブロックに分けられます。

ファイルA = ブロックA1 + ブロックA2 + ブロックA3 ＋ …… + ブロックn

これをブロック単位でHDDに保存・読込を行います。
1つのHDDに対して、ブロックA1～ブロックnまで配置した場合と
2つのHDDに対して、ブロックA1～ブロックnまでを分散させて配置した場合、
HDD1台当たりのブロック数は後者の方が少ないため、
データへのアクセス速度などが上がります。

次回はRAIDレベルなど話をしたいと思います。

RAIDとは、複数のHDDを1つのHDDのように認識・表示させる技術です。
なぜ、この様な事を行うのか。
これは、システムにハードディスクが一つしかない場合、
ハードディスクが壊れたとき、対応が取れない、というのが、大きな要因です。
また、この他にも、一つのデータを複数のハードディスクに分けて書き込むことが
可能になるため、データ書き込みの高速化も実現可能になります。

主に、企業でサーバやストレージに利用されている技術でしたが、
HDDレコーダーやBlu-rayレコーダーの普及に合わせて、
NAS（ネットワークハードディスクの一種）が普及したため、
消費者向けとしても関連のある技術となりました。

さて、RAIDにはハードウェアRAIDとソフトウェアRAIDがあります。
ハードウェアRAIDはRAIDコントローラや
マザーボード上のチップにコントローラが含まれているオンボードRAIDなどがあります。
（オンボードRAIDはRAIDコントローラに比べて、機能制限があることが多く、
ソフトウェアRAIDとして扱われることもあります）
こちらはRAID管理を行うための処理を機器やチップが行うため、
ソフトウェアRAIDに比べて、高速です。
また、ハードウェアRAIDにより構成されたディスクは、Windowsの様なOS側から
ディスクを確認すると1つのディスクとしか表示されません。
例えば、HDDが2台搭載されているサーバが有るとします。
(ディスクAとディスクBとします)
この2台のHDDでRAID構成をすると、仮想的にHDDができます。
（ディスクV1とします）
Windows側からはディスクV1のみがHDDとして認識されます。

これに対して、ソフトウェアRAIDはWindowsの様なOSの機能の1つとして、
RAIDが提供されます。
こちらはRAID管理を行うための処理をOSが担当しますので、
他の稼働プロセスと同様に処理されるため、
ハードウェアRAIDに比べると、ディスクの書き込みは低速となります。
OSの機能としてRAID構成を行うため、
HDDはサーバに搭載されている分が表示されます。
上述の例でいえば、ディスクAとディスクBが認識されており、
ソフトウェアRAIDとして構成することで、ディスクV1として認識されますが、
ディスクの管理機能で確認すると、表示上はディスクAとディスクBと表示されます。

今回は、RAIDについて、提供する機器・機能からの話をしましたが、
次回は、RAID構成について、もう少し詳しく記述します。

Webページで登録画面を作成していて、
必須入力項目への入力確認に、
RequiredFieldValidatorクラスを使用しました。

バリデーションを行うコントロール名とエラーメッセージをセットすれば、
指定したコントロールに対して、入力がなされたかクライアント側で確認することができます。

ただし、今回作成している画面が少し厄介で、
ドロップダウンリストの選択した値によって、
必須入力が変更される、という仕様を盛り込んでいました。

そこで、SelectedIndexChangedイベントを使用し、
選択した値が変更した時に、RequiredFieldValidatorの設定を切り替えるようにしました。

初めは、選択した値ごとに、RequiredFieldValidatorのEnabledプロパティに
TrueやFalseをセットしていたのですが、
これだと、Falseのセット漏れが出たりするなぁ、と思い、
一度、ページ内の全てのRequiredFieldValidatorにFalseをセットした後、
必要なコントロールのみ、Trueを設定しようと考えました。

では、どの様にして、全てのRequiredFieldValidatorコントロールに
Falseをセットするのか、考えました。
ASP.NETの各コントロールが継承するクラスにControlクラスが有ります。
このControlクラスには、FindControlというメソッドが有りますが、
これはコントロールのIDでしか探せません。
それに加え、コントロールは階層配置されており、
FindControlメソッドでは、呼出元のコントロールが有する子コントロールが
対象となります。

そこで、下記の記事を参考にし、再帰的に呼び出されるメソッドを作成しました。
下記記事では、IDを使用していますが、今回はクラス名で検索する様にします。

方法: ID を使用してサーバー コントロールにアクセスする

http://msdn.microsoft.com/ja-jp/library/y81z8326(v=vs.100).aspx

上記記事内に記載されているメソッドからの変更点は、
１．引数のIDをクラス名に変更する。
２．コントロールとIDの照合を
コントロールのクラス名と１で変更した引数と照合する。

    public static Control FindControlRecursive(Control rootControl,
                                               string findControlClassName)
    {
        if (rootControl.GetType().Name == findControlClassName)
        {
            return rootControl;
        }

        foreach (System.Web.UI.Control searchControl in rootControl.Controls)
        {
            Control controlToReturn =
                FindControlRecursive(searchControl, findControlClassName);
            if (controlToReturn != null)
            {
                return controlToReturn;
            }
        }
        return null;
    }

このメソッドを実行することで、rootControl以下のコントロールから
検索対象とするクラス名を有するコントロールを取得できます。
後は、取得したコントロールのparentプロパティで、
直近の親コントロールを取得し、
親コントロールが持つ子コントロールをforeachで回し、
GetType().Name で同一のクラス名を持つコントロールのEnabledプロパティに
FALSEをセットすれば、Webページ内のRequiredFieldValidatorオブジェクトを
無効化できます。

ちなみに、呼出元は以下の様なコードを書きました。

    // ページ内のコントロールを対象とする。
    foreach (Control pageChild in Page.Controls)
    {
        // RequiredFieldValidatorクラスのコントロールを検索する。
        var findControl = FindControlRecursive(pageChild,
                                  "RequiredFieldValidator");

        if (findControl != null)
        {
            // 検索結果のコントロールの親コントロールを取得する。
            var parentControl = findControl.Parent;

            // 親コントロールの全てのvalidatorを無効にする。
            foreach (Control childControl in parentControl.Controls)
            {
                If (childControl.GetType().Name == "RequiredFieldValidator")
                {
                    RequiredFieldValidator requiredFieldControl =
                        (RequiredFieldValidator)childControl;
                    requiredFieldControl.Enabled = false;
                }
            }
        }
    }

サーバサイドで同一のクラスを持つコントロールに
一律の操作をする際に、使えると思います。

開発用のサーバにVMWare ESXiをインストールさせようとしている社員Ｏ氏。
RAIDの設定に四苦八苦しながらも、なんとかRAIDの設定は行えましたが、
まだまだ続きます。
というより、むしろここからがインストール作業です。

空の環境にインストールする際、特に難しいことはありません。（ないはずでした……）
１．ブート時にCDからインストールするか確認
２．規約事項の確認
３．インストールするハードディスクの確認
この順に確認が出ますので、
それぞれ入力を行います。

が、今回は楽にはいきませんでした。
今回の問題は３のハードディスクでした。

どのハードディスクにインストールするか確認する画面が表示されるのですが、
RAID構成したはずのディスクなのに、物理ハードディスクが二つ見える……

RAID構成が崩れた？　と思い、サーバを再起動させて確認する。
RAID構成は崩れていない。
とりあえず、そのままインストールを続行してみました。
その後の起動で確認すると、RAID構成は崩れたままです。

どういうことだ？　と考える。
まさか、オンボードRAID（＝ソフトウェアRAID）だとよろしくないのか、と思い、
ESXi5.5のインストールマニュアルを探す。
やはりというか、下調べが足りてないというか、
ESXi5.5ではソフトウェアRAIDはサポートしていない、という一文が。
そうですか、マザーボードに載っているタイプのRAIDもアウトですか……

しかし、原因さえわかってしまえば、回避できます。
ということで、BIOSを立ち上げ、HDDモードをAHCIへ。
その後、正常にインストールは完了しました。

正直、ここまで苦戦することになるとは考えてもいませんでした。
ESXiも（バージョンが異なるとはいえ）インストールしたことはありましたから。

それでは、今回の教訓です。
インストールする環境はきちんとマニュアルに目を通しましょう。

前回といい、今回といい、事前に情報さえ持っておけば、
回避できる状況に対し、前にやったことあるし、大丈夫大丈夫と
安易に考えたために、結果として、大火傷してしまいました。

事前準備ってホント重要ですね……