杉村ウェブクラフトの得意な分野について紹介します。
Webサーバーより電子メールを送信することができます。
電子メールの送信については、いろいろな用途で使うことができます。
例を挙げると、在庫管理システムでは、在庫の一定のしきい値を超えたときにアラート（警報）メールを送信することがあります。
在庫が余剰のときは発注操作を止める。在庫僅少のときは発注リストに追加するといったオペレーションが必要になります。大量注文などにより在庫は急激な変動が発生することがあるので、電子メールで連絡が届くと早期に対応できるメリットがあります。
Webアプリケーションは、ログイン認証を行うため、ユーザーアカウントの作成と管理を行う必要があります。
杉村ウェブクラフトでは、アカウント管理、グループ管理を標準で実装しています。
メールアドレスはダミーです。
ユーザーリスト画面では、ユーザーアカウントの作成のほか、休職や退職によるアカウントのインアクティブ化（無効化）が行えます。またユーザーアカウントのグループ登録（または抹消）も行えます。アカウントの登録などの編集作業は管理者権限保有者のみが操作できます。
グループリスト画面では、グループの作成が行えます。上図のとおり、グループにユーザーを所属させることができます。特定のグループメンバー以外は秘匿としたいデータがある場合に閲覧を制限することができます。そのための基盤となる設定機能です。
Ajax(Asynchronous JavaScript And XML)（エイジャックス）という非同期通信を利用したプログラミング手法があります。具体的には、ブラウザのページ再読み込みボタンを押すことなく、非同期でサーバーとバックグラウンドで通信し、その最新情報を画面に反映させます。
このプログラミング手法を活用することにより、刻一刻と変化するデータをリアルタイムに表示することができます。
例を挙げると、証券会社が提供する株価モニタリングは、数秒～数十秒おきに株価情報を自動で取得して画面に反映します。それにより、複数銘柄の株価の動きを逐一確認することができます。
また、工場などの生産現場では生産進捗モニタリングという進捗グラフを活用します。現在の生産台数とその時間での計画台数を算出し、現在の進捗が遅れているのか進んでいるのかの判断に使われます。進捗が計画より遅れている場合、現場の士気が改善する効果が期待できます。
データベースの任意のデータを加工して、PDFファイル形式でダウンロードすることができます。
上図は杉村ウェブクラフトの見積書生成サンプルとなります。
独自のフォーマットでデザインすることができます。帳票（リスト）形式にすることで可変のデータ量に対応し、複数ページにまたがる印刷もできます。
リレーショナル(relational)とは関係という意味です。リレーショナルデータベースは、複数の表（テーブル）を用いて表同士を関係づけます。
少し難しく感じるかもしれませんが、最後まで読んでいただると杉村ウェブクラフトのシステム開発をご理解いただけると思います。できるだけわかりやすく説明しますので、よろしければ是非ご一読ください。
単一表でデータを管理した場合と、複数の表でデータ同士を紐づけた場合の例について説明します。
見積書データを単一の表で管理した場合の例となります。取引先企業と取引先企業の担当者名、件名や金額などが登録されています。
つづいてこちらは複数の表で構築した場合の例です。
取引先企業、取引先担当者、発行者を別の表に分離していることがわかります。この分離した表をマスタテーブル(master table)といいます。（単純に略してマスタともいいます。）
取引先企業名は、企業IDをキーにして取引先マスタを参照することで、企業名を取得することができます。同様に取引先担当者は、取引先担当者マスタより担当者名を取得できます。一見すると無駄のように思えるかもしれませんが、これがリレーショナルデータベースの考え方で、じつはそこに多くのメリットがあります。そのメリットについて次の項で説明します。
前項の見積書データを参考に、複数の表で構築した場合のメリットを説明します。
文字列と数値で使用するデータ量を比較すると、文字列は数値より多くのデータ量を消費します。例えば、杉村ウェブクラフトという文字列は９文字の全角文字ですが、現在主流の文字コードである UTF-8 では１文字当たり3byteで表現するため27byteも消費します。また文字列は 可変長 で管理するため文字列の長さ情報も2byte追加されて合計で29byteが必要となります。それに対して、数値の場合はわずか2byteで済みます。数値のほうが圧倒的にデータ量としては少ないと言えます。
つまり、冗長となる文字列はなるべく数値化して複数の表で管理したほうがデータが小さくなるため効率的と言えます。データが数百万件、数千万件と蓄積すると、その差は大きなものになります。
データベース管理システムでは、データベースを構築時にページという区画を作ります。ページはデータベース管理システムによって大きさが異なりますが、概ね8kb（キロバイト）であることが多いです。
データの読み書きは、必ずページ単位で行われます。１件あたりのレコードが短いほどページ内にたくさんのレコードが格納されるため、ディスク容量の使用量削減のほか、アクセスするページ数も少なくなるため応答速度の向上にもつながります。
単一表で管理する場合、文字列を手入力でタイピングするため、表記の揺らぎが発生するリスクがあります。
ここでいう揺らぎとは、同じ意味の言葉でも表記が異なってしまうことです。例えば、製パン業界で国内最大手の「山崎製パン」をある人は「ヤマザキ」と記述したり、またある人は「山﨑製パン」（﨑＝たてさき）と記述するかもしれません。このように表記が統一されないリスクがあります。表記が統一されないと、「山崎製パン」の情報をとりこぼす可能性があります。
その点、マスタテーブルを用意して関係づけていれば、マスタテーブルのデータを選ぶだけでタイピングそのものが不要になるため、揺らぎの問題は発生しません。
マスタテーブルにデータを分離しているため、マスタテーブルの内容から選ぶことになります。上図は取引先マスタより取引先企業を選択します。これにより、揺らぎの問題を解決し、タイピングが不要になります。
そうはいっても、マスタが数十件以上になると探すのが大変です。そのような場合に不便とならないように検索ボックスを設けています。
上図は「杉村」と入力し、それに該当する取引先企業が選択肢として表示されていることがわかります。
数値も文字列もインデックスを生成して、インデックス経由で検索することは可能ですが、文字列と比較して数値のほうが検索の応答速度は速いです。
杉村ウェブクラフトで検索する場合、リレーショナルデータベースでは、企業ID：１のデータを検索しますが、単一表では文字列となるため、杉村ウェブクラフトの文字列が完全一致するかを判定しなければなりません。
細かく説明すると長くなるので割愛しますが、一般的に文字列より数値のほうが検索は速くなります。
説明の都合上、マスタテーブルのフィールドは必要最低限の情報しか書きませんでしたが、本来であれば様々な情報をバインドしたほうが便利です。
上図は取引先担当者マスタです。名前のフリガナ、部署名、役職、電話番号やメールアドレスなどが一緒に登録されるので、マスタテーブルとして管理したほうが便利だということがわかります。
これまで、マスタテーブルとデータ（見積書データ）との関係を説明しましたが、マスタテーブル同士でも関係づけることができます。
取引先マスタと取引先担当者マスタは親子関係です。取引先担当者マスタには、企業IDが含まれます。そこからわかることは、杉村ウェブクラフトの担当者は杉村 悟史と杉村 六郎であり、こしがや製菓の担当者は、越谷 ガーヤであるということです。
上図は、見積書データ作成時のフォーム画面です。
取引先企業に杉村ウェブクラフトを選んだ時点で、担当者は杉村 悟史と杉村 六郎しか選べないようになっています。
今度は取引先企業にこしがや製菓株式会社を選択します。すると、担当者は越谷 ガーヤしか選べません。このように操作性の向上と組み合わせミスの防止を行うことができるのは、マスタテーブルに情報を分離して関係づけているからです。
杉村ウェブクラフトのリレーショナルデータベースの特性を活かしたシステム開発の概要がご理解いただけたかと思います。
杉村ウェブクラフトでは、各マスタテーブルの編集機能、データの検索機能を用意し、ユーザビリティに優れたWebアプリケーションの開発を第一に考えて開発します。ご興味があればお問い合わせページよりご連絡ください。