すべてのカテゴリ

Accessで介護支援記録システムを作った理由－11 これまで長い間、介護支援記録を管理するデータベースシステムをAccessを使い開発することとした経緯等について語ってきましたが、このシリーズの最後として、別の視点から見たAccessの凄さにについて触れたいと思います。 Accessのアプリケーションとしての性格は、現状、小規模かつローカルな環境下で、高度なリレーショナルデータベースシステム(RDBMS)を開発し運用するためのソフトとして定義づけられると思います。 長年にわたりバージョンアップを重ねてきた結果、動作も安定しており、データベースを動かすスピードも高速です。しかも一ライセンス当たりの価格が安く、無料のランタイムも使えるなど、他のデータベースソフトよりもコスパの良さは抜きん出ています。 しかし、Excelに比べるととっつきにくく、マクロやVBAを使ったアプリの開発も初心者にとってハードルが高いため、様々な職場で広く普及することは妨げられてきたように思います。 視点を変えてみると、これは実に「勿体ない」の一言です。 企業が自らのオープン系システムの中に、情報通信会社に頼んでRDBMSを構築しようとする場合には、データベースを操作する言語としてSQLが一般的に使われています。 SQLは優れた言語で、RDBMS開発に欠かせないものであり、様々な仕様を持つデータベースの殆どがSQLに対応しています。 しかし、SQLはデータベースに対してしか命令できない言語のため、C言語など他のプログラミング言語の中に組み込んでシステム全体を開発しなければなりません。当然ながら、このような作

Accessで介護支援記録システムを作った理由－10 私の勤務先が養護老人ホームに移り、施設独自の介護支援記録管理システムの開発を始めてからプロトタイプを作り上げるのに約3か月を要しました。 VBAのことは知っていても、実際にVBAでプログラミングをした経験がなかったため、初心者同様、VBAに関する書籍やWebから得た情報を参考にしつつ、フォームのデザインにもこだわり作り上げていったという感じです。 とは言え、老人ホームにおける介護業務や介護記録が一体どのようなものかは良く知っていたので、介護記録のテーブルと利用者のマスタデータを始めとする各種テーブルをどのように組み合わせたら良いか考えるのには、それほど苦労しませんでした。ここで大切なのは各テーブルの「正規化」です。これは、データベース上のデータの重複をなくし、整合性の取れたデータベースを設計して、データベースを効率的に扱うための手法です。またクエリと呼ばれるテーブル同士を有機的に結合させる手法も重要になります。リレーショナルデータベースシステム(RDBMS)の骨格ができた上で、次に取りかかったのは、アプリのインターフェイスに関する様々な動作の設計です。 設計の中で、苦心しながらも面白く感じたのは、データ入力に必要な複数のフォームの組み合わせ方と、一つのフォームから別のフォームにVBAコードでデータを転記する手法でした。例えば、個別利用者の介護記録を受け入れる入力フォームの中に、利用者データが入った別のフォームから利用者ID（識別コード）を送り込むようなケースです。関連づけられたデータに関する複数のフォームを並べて表示させるこ

Accessで介護支援記録システムを作った理由－9 私が介護支援記録管理システムの開発において重視したことは、パソコン操作に慣れていない職員でも、簡単で分かりやすく効率的にデータを入力できるということでした。 ポイントとして、Accessアプリでの入力作業は、よくあるスマートフォンアプリのように、いくつもの画面を遷移しながら行うのではなく、広い画面を使い、一画面で入力が完結できるようにしました。 例えば、メインの介護支援記録の入力では、日付と利用者を紐づけたコンテナ情報の中に、時系列的に一つひとつの記録を追記する形で行うようにしています。これは既成の介護業務支援システムに倣ったものです。コンテナ情報、利用者データ、介護支援記録などは複数のテーブルに保管されていますが、リレーションシップにより紐付けられ全体情報は一画面の中に表示されます。 これを具体化する入力フォームは、テーブルごとのいくつかのフォームを親子、兄弟のように組み合わせます。そうすることにより、誰でもぱっと見、わかりやすいインターフェイスが出来上がるという仕掛けです。 また、システムの進行操作は画面上に配置されたボタンをクリックして行うため迷いがなく、さらに介護内容や担当者等の定型的な入力については、ドロップダウンリストを使うことで効率化を図っています。 しかし、完成に至るまでの間、フォームの作成には相当の手間がかかってしまいます。 ひとつのフォームを一から作ろうとすると面倒なので、いったんAccessに備えられたウィザード機能を使うのですが、この出来上がりが凄くショボい！あまりにも最初のデザインが酷いので、どうして

Accessで介護支援記録システムを作った理由－8前回のブログでは、養護老人ホームという環境下で、マイクロソフトAccessの特徴を生かし、介護支援記録の管理システム開発にとりかかるまでの経緯を書きました。 今回はそのAccessの特徴を語ることにします。 Accessはもともとスタンドアロ―ンのPCソフトとして開発され、個人の能力に合わせ自由に使われることを想定しています。 データベースを簡単かつ自動的に操作するアプリの作成機能は初心者にとってわかりやすく、プログラミング言語を学んだことがなくても、マクロ機能でそこそこのアプリを開発できてしまいます。 解説本も多く、またネットにも情報が溢れているので、勉強するのに苦労はしません。 私がAccessのVBA（Visual Basic for Applications）で介護支援記録用アプリを開発しようと思ったのも、趣味的にVB（Visual Basic）やJavaScript等でプログラミングした経験があることに加えて、VBAの情報を得やすいと考えたからでした。一方、Accessの問題点や短所としてよく挙げられるのは、まず、ネットワークへの対応力が弱く、データベースを複数人で同時操作する場合に制限があることです。大人数で同一のデータベースにアクセスするとファイルが破損しやすいと言われています。またファイルサイズも2GBまでのため、大量のデータを保管し管理することができない点もデメリットとして良く指摘されているようです。 何より、アプリを開発した職員が異動や退職でいなくなってしまうと、業務内容の変更等でアプリを改変するのが難しくな

Accessで介護支援記録システムを作った理由－5 自宅用のAccessまで手に入れたあと、その後は仕事でも使うことはなく、時は過ぎていきました。しかし、西暦2000年が明けた頃、思いがけず仕事で使う機会がやってきます。仕事上の成り行きで、あるNPO団体の手伝いをすることとなり、その収支関係をデータベースを使って管理するものを作る必要に迫られたのです。 実はこの時の経験が、20年後に介護支援記録管理システムを開発することに至る大きな動機付けとなります。 なお、これからは、データベースシステムを分けて、データベース本体（データ）とは別に、マクロやVBAなどプログラムコードを使い、操作を簡便化、自動化したインターフェイス部分をアプリと呼ぶことにします。 作るべきシステムの機能としては、単式簿記による入金と出金の管理、これに伴う確認や決裁書類の作成のみでした。但し、これを操作するのはパソコンを習いたての中年女性、まだExcelも使えない方でした。もちろんAccessを自力で操作するなんてとんでもありません。もしもExcelでこれを作った場合、不慣れな操作でデータを消してしまったり、最悪、ワークシート上のテーブルや関数を壊してしまい、使えなくしてしまう恐れは十分にありました。そこで、データの入力はキーボードから行い、アプリの操作はボタンをクリックするだけで簡単にできるものをAccessで開発することにしました。 その当時の私は、テーブルとそれらを組み合わせてクエリを作るくらいの知識しかなかったため、解説本でフォームの作り方やマクロを急いで猛勉強します。難しいVBAを使うのは完成まで時間

Accessで介護支援記録システムを作った理由－4 私がAccessのようなソフトを使い始めた理由は、まず自分の仕事にデータベースを使いたいという、純粋に個人的な理由からでした。 1980年代後半にMS-DOSがパソコンOSの主流となり、社会にPCが普及していく中、私は個人でも勉強をすればデータベースが操作できる時代が来たことを知ります。 最初に関心を持ったのはdBASEⅢというソフトでした。 プログラムを書くことは、PCがマイコンと呼ばれていた時代にゲームプログラミングのため習得したBasicで経験しており、その後、ゲームを高速化できるマシン語にも手を染めていました。 なので、dBASEⅢも楽勝！という気分で取り組み始めましたが、実際にやってみると、やはり仕事の合間に独学でデータベースシステムを作ろうとするのは無理がありました。 実務者とSE、両立の試みはすぐに挫折します。 その後に異動した職場で、DOS版表計算ソフトのLotus 1-2-3をデータベース操作に利用するという、楽な方法を覚えます。1991年のことでした。 紙の帳票から必死に手入力したデータでデータベースを作ったあと、検索や抽出ばかりでなく、統計的な分析手法で、今までよく見えなかったものが明確に見えるようになる面白さを知ったことが大きな収穫でした。 そこで次に異動した職場では、Windows版 LotusSuperOfficeにバンドルされていたApproachというソフトを見つけ、これを使ってみることにします。また、自分でデータを打ち込む無駄を省くため、メインフレームからCSVでデータを抽出してもらい、これを

Accessで介護支援記録管理システムを作った理由－３前回の続きです。 データベースを基本とするシステムををExcelで作りたいとき、操作の効率性などを向上させたい場合は、フォームやVBAを使ったほうが良いでしょうか。 私の経験では、テーブルに格納されるデータ（レコード）件数が少なく、あるいはデータを構成する項目（フィールド）数が少ないときは、直接テーブルを操作するか、関数を使って抽出したほうが効率的と思っています。 しかし、レコードの件数が数千、数万単位となり、しかもフィールド数が多い場合、さらに、フィールド数が少ない場合でも入力されるデータの内容が多岐にわたっている場合は違ってきます。 まず、レコード件数が多くなれば多くなるほど、自然と検索や抽出を行う操作が増えていきます。 さらに、例えば売上データから、品目別に売上高を計算しようとすると、品目数が多ければ、自分でフィルター条件を設定するだけで手間がかかります。 一方、関数でデータを抽出しようとする場合でも、調べたい品目数が増えるにつれて関数が複雑化し、計算用のワークシートも増えて、結果を表示する目的のシートが探しにくくなります。この点は、前回のブログでも触れました。 従って、この場合、ExcelのユーザーフォームやVBAを使ったほうが効率的、と言えるのでしょうか。 私は、このレベルになってくると、Excelでデータベースを操作しようとすること自体に意義を見出しにくくなる、と考えています。 Excelは極めて優秀なソフトです。 データベースまで扱える充実した機能性と、何より様々な姿に変わるワークシートという自由さを備えている

前回のブログではExcelの使い勝手の良さについて触れましたが、今回はExcelのデータベース機能について語りたいと思います。Excelではリスト化されたデータを簡単にデータベースにすることができます。活用されている方も多いと思いますが、知らない方のために説明しますと、この場合、リスト化された1行のデータはデータベースで言う「レコード」となります。同様にデータを構成する項目は「フィールド」と呼ばれ、全体を「テーブル」と呼びます。当初作ったリストはそのままでも並べ替えなどデータベース的な操作は可能ですが、データ数が多かったり、住所録のように後でデータを追加するなどの操作が必要なら絶対にテーブル化したほうが良いです。 また、データの入力規則機能を使えば、入力時に選択用のリストを表示させることができ、これは大変便利です。 Excel2013以降のバージョンでは、制限はありますが、Accessが持つリレーショナルデータベース(RDB)機能も備えるようになりました。 これは、2つのテーブル、例えば商品の売上データのテーブルと営業担当者のテーブルを関連づけ、ピボットテーブルというものを使い、例えば担当者ごとの売上額の集計を行うことができるような機能です。この程度であれば、何も専門的なAccessなど使う必要はないかも知れません。 私が介護施設に勤務していたときは、Excelで必要な情報を集めたテーブルを作り、そこから該当する情報を抜き出して、個別の書類を作成するようなシステムを沢山作り上げました。 例えば、訪問介護の毎日の稼働データから集計を含む日報や職員ごとの実績表を作ったり、入居者全員

前回のブログで、表計算ソフトのExcelでも普通にデータベースを扱えることに触れました。それなのに、なぜ私がデータベース専用ソフトのACccessを使う方向に進んでいったのか、その理由をこれから披瀝していこうと思うのですが、その前にExcelについて語ることにしましょう。MS-DOS時代に一世を風靡した表計算ソフトのロータス1-2-3は、OSがGUI（グラフィカルユーザインタフェース）を備えたWindows時代に移行すると、たちまちそのシェアをExcelに奪われます。 Excelは非常に軽快かつ多機能で、現在もChatGPTが使えるようになるなど進化を続けています。単なる表計算ソフトの領域を超え、ワープロとして使われたり、VBAを利用してゲーム製作までできるなど、非常に応用力が高いソフトであることはご承知のとおりです。 1995年に画期的なWindows95がリリースされると、私が働いていた部署でもWindows PCの導入が進みます。それとともに、Excelがワープロソフト代わりとしても使われるようになっていきました。 当時、ワープロ専用機としてシェア第1位だった富士通の"OASYS"が、Windows PC版ソフトへと移行する中でその優位性を失い、またMS-DOS版からWindows版にようやく移行したジャストシステムの"一太郎"も、ExcelにWordをバンドルするマイクロソフトの戦略によって、シェアをWordに奪われてしまいました。このあたりは、経済的な成功体験とガラパゴスな技術に溺れて、世界標準から取り残されていく日本の姿を予兆していたのかも知れません。 ところが、実

前回のブログではマイクロソフトAccessとの出会いについてふれましたが、なぜデータベースに惹かれたのかを語りたいと思います。私が就職したのは1978年、地方公務員としてでした。最初に配属されたのは、医療費助成を担当する部署でしたが、非効率的な手作業が多いことに驚いた記憶があります。 このとき始めて具体的に稼働しているコンピューターのことを知ります。いわゆる「メインフレーム」ってやつです。バッチ処理と呼ばれる月1回の処理方法で、業務データの入出力が行われていました。紙の受給者台帳、医療機関名簿、振込リストなどを使って仕事をしながら、このとき、世の中の情報はほとんどデータベースで整理され、それが日々更新されていることを知ります。 現在ではIT化が進み、システムへの入力はオンライン化され、帳票類も随時出力できる進化を遂げていますが、その根本に変わりはありません。 ちなみに、役所も含め、事務作業の生産性が低い理由の一つは、大量の紙文書の存在があるからだと思っています。少しずつでも無くしていくことが、生産性向上につながるはずです。 情報におけるデータベースの存在意義、効果を知った私は、自分のデスクワークにもデータベースを使いたくなります。 それが実現したのは1980年代の末頃、MS-DOSパソコンがようやく職場に普及し、ロータス１-２-３を使い始めてからでした。何百件もあるデータはすべて自分で打ち込み、データの並べ替えやフィルタリング作業は、マクロで自動化して仕事に役立てました。Excelなどの表計算ソフトでデータベースを作り、操作するのは今ではポピュラーとなっていますが、当時としては

本日、私が開発した介護支援記録管理システムの紹介動画をアップしました。これを記念に何か皆さんの参考になればと思い、ブログも始めることにしました。気の向くままに投稿しますので、よかったら読んでください。さて、40代でマイクロソフト Accessを仕事などに使い始めてから既に30年近く経とうとしています。現在までに至る歴史のきっかけは、当時、最も表計算ソフトとして輝きを放っていたロータス 1-2-3を使って個人で仕事に必要なデータベースを作成し、マクロを組み合わせてその便利さに気づき感動したことでした。1991年、ロータス社は個人向けのデータベースソフトとして、Approachというソフトを開発・販売します。私も自分の仕事の中で、本格的な集計や分析などに使用することにしました。しかし、実際使ってみると集計にとても時間がかかり、フォームの作成も非常に面倒くさく、使い勝手はイマイチでした。そうすると間もなく、優秀なデータベースエンジンを持つAccessがマイクロソフト社から発表されます。これがAccessとの必然的な出会いとなりました。このブログでは、ExcelほどメジャーではないマイクロソフトAccessの良さを再確認しながら、私が開発した介護支援記録管理システムについて語っていきたいと思っています。

まず、端末管理データベースを作成するためには、以下のようなテーブルを作成することをおすすめします。 端末テーブル 端末ID、端末名、型番、購入日、リース開始日、リース終了日、所在地IDなどの項目を持つテーブルです。 所在地テーブル 所在地ID、所在地名、所在地住所などの項目を持つテーブルです。 このラインより上のエリアが無料で表示されます。 リーステーブル リースID、リース会社名、リース契約日、リース開始日、リース終了日などの項目を持つテーブルです。 変更履歴テーブル 変更履歴ID、変更日時、変更内容、変更前値、変更後値などの項目を持つテーブルです。 これらのテーブルを作成したら、以下の手順でリレーショナルシップを設定することができます。 端末テーブルと所在地テーブルのリレーションシップ 端末テーブルの所在地IDフィールドを所在地テーブルの主キーに設定します。これにより、端末と所在地の関係性を表現することができます。

職業柄、厚生労働省関連のWebサイトで調べものをする機会が多いです。行政は色々なデータを公開していますが、CSVファイルやExcelファイルなのでデータの絞込みや集計が煩雑になります。今回、医療機関の情報をデータベース（Microsoft　Access)に取り込んでみたところ思いのほか実用的だったのでご紹介してみます。内容は自分のブログで紹介したものです。医療従事者向けのものにはなりますが、他業種でも所轄官公庁が公開している情報は多くあると思いますので応用は出来ると思います。私の住んでいる中国地方の厚生局のサイトから医療機関の届出情報をダウンロードしてみました。保険医療機関には施設基準の届出という仕組みがあり、何をするにも国に申請して許可を得る必要があります。施設基準とは 施設基準とは、医療法で定める医療機関および医師等の基準とは別に、健康保険法等の規定に基づき厚生労働大臣が定めた保険診療の一部について、医療機関の機能や設備、診療体制、安全面やサービス面等を評価するための基準になります。 診療報酬の中には、この施設基準の届出を行うことで算定が可能となるものがあります。 施設基準ごとに対象となる患者さんや算定の要件、届出の要件が定められています。coconalaブログでは他のサイトへリンクを張れないようなので興味のある方は「医療従事者のためのAccess」で検索してみてください。このように医療機関毎に取得している施設基準の一覧表を簡単に入手することができます。ただしExcelはあくまで一覧でしかないので、フィルターを駆使して欲しい情報を検索するしかありません。Accessを利用

データベースの元になるCSVファイルから情報をまとめてデータベースを作成する際に注意点がありまわりのす。利用者情報の登録情報に抜けがないことはもちろんですが、利用者名を削除したり、上書きしてしまうと全体数の把握が困難となり、データベース化が困難となってしまいます。こんな時には、利用者名を記載する上で一定のルールを作成し、入力する職員が共通認識の上でルールに従ってもらう必要があります。そのためには、データベース化する利点が、ルールを守る手間を上回る必要があります。ここでもプレゼンテーションが必要になり、9割の人が納得する利点を提示しないといけないと考えます。しかし、１割くらいの職員は、どうしても反対されますので…。しかし、データベース化した後にエラーばかりになると賛成してくれた職員に迷惑をかけます。やるなら、徹底的にデータベース化が大事です。

マルチスレッドデータベースサーバで必要なメモリー管理本ブログも5回目となりました。前回のブログでは、マルチスレッドデータベースサーバでCGIと通信するソケットプログラミングについて詳細を書いておきました。今回は、マルチスレッドデータベースサーバで重要なメモリー管理についてお話します。この話は、前々回のブログの内容とかなり関連しますので、一応リンクしておきます。C言語でメモリー領域は、1）関数内で宣言する固定的なメモリー領域のもの（スタック上に確保される）と、2）malloc()などの関数で、動的に確保したメモリー領域があります。1の場合はスタック上に確保されたものだから、そのメモリー領域は、その関数内と、その関数から呼び出される関数の中だけで有効です。そして、関数からreturnで抜けると、そのメモリー領域はスタックから解放されて、以降、参照できなくなります。いや参照してもよいですが、内容はどうなっているか不明です。2の場合は、ヒープ領域にメモリが確保されていますから、プログラム終了までメモリー領域は解放されず、もし、解放する必要があるときは、free()で明示的に解放する必要があります。WEBサーバでCGIは、httpdがリクエストを受けた段階で立ち上げられ、終ると終了しますので、CGIの中でmallocなどによるメモリー確保をしても、それは終了とともに解放されます。しかし、マルチスレッドのデータベースサーバの場合は、スレッド内で確保したメモリー領域は、スレッドが終了してもサーバ自体が動いている間は、解放されません。ですから、スレッドが終了するときに、明示的にメモリーを解放す

ご要望があり、sampleプログラムを作りました。画像は、そのプログラムから出力したものです。要望内容・ヤフオクからカメラやレンズを多々購入したいと思っています。 ・信頼できそうな出品者から購入したいです。 ・「カメラ、光学機器」「レンズ」分類を対象に、 ・取引件数、よい評価率、ストアor個人などの条件設定することで、 　それに該当する 　①出品者ID 　②良い評価率 　③①が出品されている商品名、現在価格、即決価格、入札件数、残り時間 　④③にリンクが張られている というものでした。最終的に、下記3項目を、条件下に出力しました。01　カテゴリー 02　総合評価　100以上で、 03　評価率 　　99.00%以上が抽出対象　自動データ収集プログラムだけでなく、ここから画像ダウンロード機能や、指定時刻にデータ収集予約実行機能（毎朝10時とか）とか、Excel形式ではなく、スプレッドシートへ連携し、データをアップロードするなんてことも可能です。　なかなか人の手でして貰うには、単調で苦痛な作業・・・そういったものは、是非自動化を検討してみてください。ご相談にものりますので。　せっかくの高いパソコン・・・毎日いっぱい働かせてあげてくださいね。

┏━━━━━━━━━━━━━━━━━━━━━━━━━━┃ ◆ 興味を持たれた方はDMください。対応します。┗━━━━━━━━━━━━━━━━━━━━━━━━━━不動産屋さん向けに、ちょっと便利なツールを作成しています。郵便番号を入力すると、近隣の施設を自動検索するものです。現在のところ、対象の施設は　　＊小学校　　＊中学校　　＊病院（大きな病院／診療所）　　＊バス停です。ツールの中身は、ゴリゴリに作成しています。検索に使用しているデータは、国土交通省や国土地理院などがXML形式やCSV形式で公開している位置情報データです。アプリケーション起動時に、それらのファイルを解析後、メモリ上に展開しておきます。ツールの基本的な動きとしては、　　＊郵便番号を入力します。（住所に含まれるキーワード入力で、オートコンプリートする機能あり）　　＊郵便番号から緯経度を逆引きします。（国土交通省 位置情報データ）　　＊物件住所の緯経度と各施設（学校／病院など）の緯経度から、緯経度の差を求めます。　　＊緯経度の差から、地表上の距離を計算します。（ヒュベニの公式）　　＊距離が近い順に施設をソートして、画面に表示します。｀｀｀｀｀｀｀｀｀｀｀｀｀｀｀｀｀｀｀｀｀XMLファイルやCSVファイルの読込みは、原理的に どうしても時間がかかるので、アプリケーション起動時にスレッド処理で対応しています。オートコンプリートがとにかく便利です。今後は、以下の自動検索機能も追加できればと思っています。＜データあり（できそうな見通しあり）＞　　＊JR／私鉄 最寄り駅　　＊地価公示情報　　＊避難施設　　＊土砂災害危険箇所／警

最近、組織内でSharePointサーバを導入するケースが増えています。その中で、従来のファイルサーバからSharePointサーバに完全移行した際に、Excelマクロが動作しないなどの問題も発生していると聞きます。　・従来のファイルサーバ（例：￥￥サーバ名￥部署名）　・SharePointサーバ（￥￥テナント名＠SSL￥DavWWWRoot）実際、SharePointサーバに完全移行した後で、従来の作業を、従来通りの感覚で行う対策は難しいです。私達は、購入者様の「こういうことをしたい」を丁寧にヒアリングして、現実的な解決策を 一緒に考えさせて頂く、ということを基本スタンスにしています。｀｀｀｀｀｀｀｀｀｀｀｀｀　私達の感覚では、Microsoft SharePointの位置づけは、チーム作業を支えるデータ共有プラットフォームだと思っています。　表形式データの中身を、WEB上のデータベース（名称：SharePoint List）に置いて、ユーザインターフェースとしてExcelを使用するような形が想定されているのかと。　そうすれば複数人のチーム作業で、リアルタイムでデータが共有される、といった青写真が描かれているようにも思えます。　本質的には、既存のExcelデータ（管理台帳など）をSharePoint List上にアップロードして、クエリを使用して、そのデータと連携するのが対策となるかと思います。　具体的には、クエリで読み出して集計作業を行ったり、Excelマクロを組んで SharePoint List上のデータを追加／編集・更新／削除したり。　一方で、私達は、日常の業務に追わ

Basicというのはとても理解しやすく分かり易いプログラミング言語です。 中学生程度の英語力もで意味が分かる命令文（コマンド）しか無く、構造もシンプルです。 そして子供の頃に没頭したことは大人になっても、そうそう忘れるものではないのだということが分かりました。 勿論BasicとVBAは似て非なるものなので、そっくりそのままでは無いのですが基本的な部分は踏襲されており、簡単な処理を組めるようになるにはそれほど時間はかかりませんでした。 Accessはデータベースとしてシステムを組むのは簡単ですが、ある程度手を加えないと使い勝手が良くありません。が、補助的に自動化を組み合わせることでかなり便利になります。 例えば毎日の日付を手入力するのは面倒で更には誤入力の危険性もあります。そこで日付は自動入力にするのですが、もっと言えば将来の日付を事前に作成しておくこともできます。 ＶＢＡで１０００日分のレコードを作ってやれば１秒もかからずに３年分のカレンダーが作成できます。Ｅｘｃｅｌでもカレンダーは簡単に作れますが、セルの範囲などは使用者が管理する必要があるためどうしても操作上のミスが発生します。 Accessではシステムが管理してくれるので、使用者はカレンダーを意識しなくても当日の日付の枠にデータを入力するだけで良いのです。 　　　　（カレンダ作成のコードサンプル）AccessではVBAを使わないと出来ないという仕事はありませんが、上手に使えば入力を簡素化したり誤入力を防いで、使用者を補助してくれます。 Excelでは、４月分を印刷したつもりが５月分のデータを参照していた。などということが人

相変わらずAccessの使い方は分からないけれど、時間があるときに開いては何かのデータを打ち込んで、どのような動きをするのかを確かめていました。 テーブルの見た目はExcelと同じような感じなので、何となく使えそうな気がしてきました。むしろデータを入力するにはExcelよりも使い勝手が良さそうな気がします。 実際、Accessではフィールド（Excelでいうところの行見出し：一番上の行のデータ名）を定義するだけで、後は１行ずつ入力できるのでExcelよりも簡単だと思いました。 （Accessのテーブル：入力に関してはExcelよりも簡単です。）ところがデータを入力していく内に、内容をコピペするのが意外に面倒でそもそも同じ内容のデータを何回も入力することに疑問を覚えました。 同じ相手に対して複数の取引があり、相手先を何度も入力して取引を入力するような場合です。Excelであれば縦にマウスをドラッグすれば、一斉にコピーできるのにAccessでは１つずつしかコピペできないのです。 他にもテーブルでの入力は何かと制限が多く、不便を感じ始めた頃に次のステップであるフォームの存在を知りました。 （これらはダミーデータ作成サイトで生成した架空の情報です）フォームでは自分がデザインしたレイアウトで、思うように入力欄を配置して自由に入力することが出来ることが分かりました。 コンボボックスで入力対象の候補から選択して入力したり、入力結果を計算して別の欄に入力したり色々と便利に使えるようになりました。 こうしてフォームが使えるようになったことで、「同じ取引先を何度も入力する」というのはそもそも間違い

YouTubeでも紹介しています。是非ご覧ください。世の中は便利になり、power query　power pivotとうがあります。 なんちゃってデータベースです。 しかし、バッタもんは、どこまで行ってもバッタもんです。 Power Query Power Pivotなんて使わない 今回は、クエリについて説明します。 以前に、Excelユーザーが知らないデータベースの作成方法等を紹介しました。 私の個人的な意見としては、私の趣味における競馬には、全く利用できません。 なぜかというと、私は、膨大なデータの中から、統計で、競馬の必勝法を、探しています。 四半期とか、先月とか、そんな話ではありません。 競馬は通常、土日で、6開催あり、約1,000頭の出走があります。 1ヶ月で、約4,000頭です。 そして、検索機能を付けて、その結果を、また、テーブルに保存するという内容です。 その中で、周知の事実かもしれませんが、結構、役に立つ競馬の必勝法を紹介します。 このブログはこんな人にお勧め ACCESSを勉強している人 ACCESSでクエリを勉強している人 競馬で高確率で、的中する情報が欲しい人 このブログを、読み終わるころには・・・・ データベースに関しては、欲しい情報が、すぐに抽出できなければ意味がありません。 実務においても、競馬においてもです。 今回は、グループ毎に抽出します。 フラグを立てたデータから、グループ全体を抽出します。 クエリを利用して、個人から全体を見る 木を隠すなら森。 このような言葉がります。 確かにその通りですね。 隠した木が、他の木に紛れるからです。 競

パソコンの購入を許されてからは夢のような毎日でした。 おおまかな構成は決めていたのですが、予算内で最大の満足を得るため色々な会社のパンフレットを集めては、細かい性能を比べて夢を膨らませる日々です。 選択したのは当時おそらくもっともメジャーなＮＥＣのＰＣ－８００１というマシンでした。それにカラーディスプレイとデータを読み書きするカセットレコーダーをセットで買って貰いました。 (画像はWeb上のものです）テレビで「アルト４７万円」なんていうコピーがコマーシャルで流れていた頃ですから、軽自動車１台に近い金額だったのだと思います。 今はもう亡くなった祖母が大きな資金援助をしてくれたことを後で知り、今でもずっと感謝の気持ちを忘れていません。今のPCスキルが身に付いたのは祖母のおかげだと思っています。いつもニコニコして笑顔を絶やさない小柄な優しい祖母でした。私も人の親となり、子供がチャレンジしたいことは出来る限り支援してやりたいという気持ちを持たせてもくれました。 さて、家ではパソコンを触る時間がいくらでもあります。最初の頃はゲームに没頭していましたが、やがてプログラムを作る面白さを知ることになります。当時のパソコンにはBASICというプログラミング言語が標準で搭載されており、NECのパソコンにはMicroSoftのBASICが乗っかっていました。もちろんWindowsが登場する遥か前の話です。 BASICというプログラム言語は非常に分かり易くできていて、少しなれてくると色々なことができるようになってきます。ただし、処理が非常に遅いので上級者になると機械言語という難しい領域に入っていきます

　SharePoint Serverとは、マイクロソフト社が提供する、企業向けサーバー製品です。表形式のデータベースをチームで共有したり、ユーザ毎にアクセス権を振り分けたりして、共有したデータを安全・確実に扱うことができます。　一般に、作業はブラウザ上で行われますが、今回は、データ追加や編集、メンテナンス作業の自動化を目的として、Excel VBAでツールを作成してみました。　　ブログ記事に起こした理由は、MySQLなどの広く普及したデータベースと比較して、SharePointへのクエリは、インターネット上にあまり情報がなく、コーディング作業に大変苦労したためです。　公開するコードは、部分的なものになりますが、これがどなたかの参考になれば、大変うれしく思います。（１）Excel⇔SharePoint間通信の基本的な仕組み　Microsoft Office製品には、ADO（ActiveX Data Objects）と呼ばれるデータベースを操作・参照するパッケージが含まれています。今回は、これを使用して外部データベース（SharePoint）へ接続します。　Visual Basicエディタ＞参照設定から

　何種類かのデータベースを扱う技術者にとって、専用ツールを使用したクエリテストは避けられないものです。　　私がストレスを感じるのは、データベースエンジンごとに、ユーザーインターフェースの使い勝手が全然違って、「ただクエリをテストしたいだけ」なのに、クエリに集中できないことです。　そこで私が愛用しているツールが「WinSQL」です。　　　www.synametrics.com/SynametricsWebApp/Download.do?ProgName=WinSQL　これは様々な種類のデータベースに対して、一つの共通したインターフェースからクエリを発行することが出来るツールです。　これを使用すると、データベースにアクセスするプログラムを開発する、一般的な手順の中で(１) 画面設計／作成(２) DB接続※場合により、トランザクション処理を開始。(３) SELECTクエリでテーブルデータを読込み。(４) (３)項の結果に応じて、INSERT, UPDATE, DELETEなどのクエリを発行。(５) SELECTクエリで、データの不整合がないか確認。※場合により、トランザクション処理を終了。といった流れの (３)(４)項を 効率的に進めることができます。非常におすすめのツールです。

　Windowsプログラム（VB.netやExcel VBAなど）からデータベースに接続する場合、ADO (ActiveX Data Object)を使用したコーディングが必要となります。　このコードは、外部データとの通信に不慣れなプログラマにとって、やや分りづらいものです。　そこで今回の記事では、中級者の方を対象として、Excel VBAを使用したデータベースアクセスの基本的な動作イメージを紹介したいと思います。　どのようなプログラムを組むにせよ、全体のデータフローがイメージできているか否かは、その後に進めるコード記述作業を、大きく左右すると考えます。　まず、全体の流れです。これは非常にシンプルです。(１) 対象のデータベースに接続する。　　データベースの形式は様々です。ファイル形式のものもあれば、データベースサーバとして独立したPCやサーバを立てている場合もあるでしょう。あるいは、Microsoft Shrepointなど メーカがサービスとして提供しているWEB上のデーがベースサーバもあります。　　まずはじめに、これからクエリを発行したいデータベースを特定できる形で、データベースに接続要求を行うことが、最初に行う作業になります。(２) データベースから接続応答が返ってくる。　　接続要求を受けたデータベースサーバ（対象がファイルの場合はデータベースドライバ）から、接続を受け付けるか／否かの応答が返ってきます。　　(１)項の接続要求にて、そのときに指定したユーザ名やパスワードなどの認証情報を元に、データベースサーバ（あるいはデータベースドライバ）が判断した結果となります。　　

YouTubeでも紹介しています。　是非ご覧くださいBIGデータを、上手に利用するには、データベースの作成が必須です。 これは、PowerQuery　や、Excelがいかに優れていても、ACCESSには勝てません。 その説明をしたいと思います。 データベースを作成するには？ こんにちは。伊川です。 ACCESSって、わからない、難しい、そんなことを、よく耳にします。 もっとも、ACCESSではなく、お金があるなら、他のデータベースを利用すればいいと思います。 Excelや、PowerQueryは、整形されたデータベースを前提にしなければなりません。 例えば、PowerQueryを利用すると、文字の分割等は、Excelよりもはるかにカンタンです。 しかし、それは、データベースを設計するときに、分割をしておけばいいだけの話です。 伊川直助⇒これは、絶対にやってはいけません。 伊川　直助⇒これは、まだマシです。しかし、スペースが全角なのか、半角なのかで、SQL文が変わってきますし、入力する人が、半角、全角は気にしないと思います。 このような場合に、PowerQueryなどを利用すると、楽になるというだけです。 伊川 直助 このように、姓と名は、絶対に分けるべきです。 伊川　直助を、分解するのは難しいですが、合体させるのはカンタンだからです。 このようなことを念頭において、データベースを作成すれば、その時点で、月の処理時間は、10時間は変わります。 余談ですが、私は、競馬はで、市販されている、4つの指数と、血統と、異常オッズ、その他の指数、約12種類を、毎週ACCSSに入力しています。

定期的にブログを更新しようとは考えているのですが、ありがたいことにシステム構築の依頼も増えて、なかなか記事が書けていませんでした。 うららかな春の日、久しぶりに窓を開けて爽やかな風とともに音楽など聴きながら少し時間ができたので子供の頃の話を書いてみようと思います。私が小学校高学年の頃に家庭用パソコンが普及し始めました。 普及とは言っても電気屋さんに置いてあるという意味で、非常に高価な代物でどこの家にでもあるというものではありません。当時、友達に誘われて近所のPCショップに入り浸っていました。そのお店はNECの販売店で主に企業や学校にパソコンを納入するショールームの様な所でした。 お店の人達とも仲良くなり、とても居心地の良い場所でした。 当時まだWindowsなどは無く、画面も白黒がメインでした。 今時の人には信じられないと思いますが、漢字すら表示することは出来ず、増設スロットに漢字ROMという部品を差し込んで漢字を表示するのですが、その部品が５万円近くするのです。 最上位機種になると本体３０万円、モニタ２０万円、外付けディスク２０万円、ドットプリンタ２０万円、フルセットで１００万円近くしました。 私の月の小遣いが１０００円程度の頃です。そんな時代ですから、自由にパソコンを触れる環境というのは非常に魅力的でした。 では、パソコンで何をするかと言えば、主にはゲームなのですが既製品のゲームソフトは非常に高額なためとても小中学生に購入できるレベルではありません。 ではどうするか？というと、パソコン雑誌にプログラムが紹介してあるのでそれを自分たちで入力するのです。 機種別にプログラム言語

始めに書いておきますが、Accessバックアップの考え方を書きます。 実際のコードは探せばいっぱいあると思うのでそちらを参照ください。 バックアップの考え方なのでAccess以外にも当てはまると思います。Accessのファイルってたまに壊れる事があります。データベースだから壊れると困りますよね。なのでAccessでバックアップをとるのは非常に重要になります。 データベースのソフトなので言わずもがななのですが。 でも、Accessは自動でバックアップしてくれないのです。 そこでユーザーが使い易いバックアップの設計が必要になります。 設計なので様々な事情や前提から色々やり方がわかれるのですが、 Accessバックアップにおける私の考えを纏めておきます。 こうしなきゃいけないというものではないので、参考程度にお読み頂けたらと思います。Accessのバックアップの考え方1. バックアップは手動と自動、両方できる方がよい。 　当たり前なので偉そうに言う事でもないですね。 2. 手動でバックアップしたファイルと自動でバックしたファイルはファイル名等で判別できた方が良い。 　判別できなくてもいいけど、できた方がよいですね。 3. Access外部でバックアップを取る手法もあるが、Access上からバックアップできた方がよい。 　これは設計で分かれる所ですが、ユーザにとってソフトは少ない方がいいとの考えからです。 4. バックアップファイル(またはフォルダ)名には、日時を入れた方がよい。 　これも偉そうに言う事じゃないですね。当然の事です。 5. バックアップファイルでそのまま運用させない様な

プログラムのメモリの使用量同じ様なデータの処理を行うプログラムでも必要なメモリの量はどの様に作るのかによって変わってきます。先日から紹介している回路設計の支援アプリでも結構変わってきます。この記事では、どの様に変わってくるか少し詳しく説明してみました。基本的なデータの量は同じ当たり前ですが、扱うデータが同じ場合、トータルで扱うデータ量はほぼ同じになります。 しかし、冒頭で書いたように、同じ様なデータの処理でもどの様に実装するかによって、必要なメモリ容量は変わってきます。 例えば、データがファイルにある場合、必要なデータだけをファイルから読み込んで使えば、実際にプログラムで使用するメモリの量は抑える事ができます。データの量は変わりませんが、プログラムの実行に必要なメモリ容量は違うという一つの例です。これはお金の話を考えるとわかりやすくなります。ある人が所有しているお金の量は例えば銀行に置いてあるお金と手元にあるお金の合計になると思います。全てのお金を持ち歩く場合、銀行から全てのお金を引き出して持ち歩く事になります。しかし、ほとんどの場合は、持っているお金（資産）を全部持って歩くケースはありません。必要な分だけを銀行から引き出してお財布に入れて持ち歩くと言うのが普通です。プログラムでも、同じ様な考え方をする事ができます。ネットリストのデータを全て読み込んで、その中から必要なデータを処理するという方法も取れます。しかし、必要なデータだけを読み込んで処理する事を考えると、データを置く場所（メモリ）を節約する事が可能になります。必要なデータだけを使う方が便利？では、もう少し具体的に回路の

アプリの中のデータの形アプリの中で扱うデータの形は同じデータでも目的や利用するプログラミング言語で変わってきます。この記事では、プログラムの中で扱うデータの形の例について紹介します。ネットリストのデータの形先日紹介した、回路図の接続情報であるネットリストを読み込んだ時のデータは、Python の「Dictionary」というデータの形を使いました。 Python で処理する場合には、扱い易いデータの形ですが、実際には、同じネットリストのデータでもデータの持ち方には別のデータの形にしても扱う事が可能です。例えば同じ Python を利用する場合でも、「Dictionary」以外だと、例えば「Net」というクラスを作る方法もあります。 Python はオブジェクト指向の記述方法もサポートしているので、少し複雑な回路設計支援のアプリを書く場合、クラスにして、Net のデータを扱うメソッド（method）を一緒に実装するとプログラム全体の見通しが良くなりますし、モジュールの再利用もやりやすくなります。先日の例で「Dictionary」を採用した理由は、例としてできるだけシンプルに実装した方がわかり易いと思ったので Python の Dictionary を利用して、他の処理は関数で実装するという方法を採用しました。他の言語で実装したらどうなる？次に、Python 以外の言語で実装する場合を考えてみます。 例えば、Python ではなくて、Javascript で実装する場合には、どうなるでしょうか？一つの方法は、上で紹介したように Javascript もオブジェクト指向の記述が可能な

書類作成のための入力をデータベース化して活用できる一例ITのインフラが整った企業であれば、申請書類を手書きして担当者へ提出するような流れは無いのでしょうが、そうでなければ出張や休暇の申請書類を手書きで提出していると思います。私の職場もそうです。手書きでもWordやExcelで清書印刷しても同じことですが、紙の情報しか残りませんから実施したら書類は保管ファイルへ移動されるだけです。 何かしらの台帳に転記されて管理はされるでしょうが、それが利用されることはありません。一方で情報をデータベースに入力した場合を考えてみます。 情報を入力するのは申請者です。出張申請書を例に考えてみます。 所属部署、氏名、出張先、出発日時、帰着日時などの情報を入力して出張申請書を作成します。 どの部署でも同じように出張申請書を入力して印刷できる環境を整えます。 同じ仕組みで休暇届もデータベースに入力して印刷できるようにします。 出張申請書と休暇届の情報を併せてカレンダー式に表示させることで、不在予定者の一覧が完成します。予定表に名前が無ければ、申請書類が出ていないということなので本人の責任です。 行き先が入力されているので、出張費の清算も簡単です。また、休暇管理は勤続年数と関係して管理が複雑になりがちですが、入力された情報を利用すれば容易に管理できます。 部署ごとの有給休暇取得率もすぐに計算できます。 職員は手書きの手間が省力化できて、簡単に申請書類を作成できる。 管理者は入力されたデータを基に予定や実施を管理することが容易になる。 すべての予定は入力されているので、出張報告書が提出されなければ実施されて

以前経理を担当していた時の話です。 医療機関では医薬品や医療機器をはじめ清掃や設備、事務用品に至るまで非常に多くの取引先があります。 月末締の請求書が届いたら翌月に支払いをするのですが、取引先によって２か月後支払いとか３か月後支払いなどと個別に支払いサイトを設けていました。 当時の上司は、数千万円の医薬品の支払いを先延ばすことで金利負担だけでも大分得しているんだと豪語していましたが、請求月と支払月が取引先ごとに異なるため管理が大変でした。 同じ月の請求書を２か月続けて振り込んだりして、期末の残高確認が合わず決算前に慌てたこともありました。 これを前任者から引き継いだExcelで処理していたのですが、シートには５０社近い取引先が縦に並べてあり、延々と右に向かって請求月と金額が足されていくという代物で、金額を間違えたり、振込先を間違えたり、毎月のように後処理に追われていました。 今思えば多額の現金を扱うにも関わらず、何ともいい加減な仕事をしていたのかとは思いますが当時はそれが精一杯で、一般企業であれば到底許されなかったでしょう。 他にも多くの業務を担当しており、限られた時間の中で仕事の精度を上げる必要に迫られ追い詰められていました。もっと効率的に処理が出来ないか日々考えていました。 当時のPCにはOffice２００３がインストールされており、その中にAccess２００３が入っていました。データベースソフトがどのような働きをするのかは分からず、どう使用するのかも全く知らない状態でしたが、なんとか現状を打破出来る術は無いかと試行錯誤し、何となく雰囲気を掴むことが出来ました。 そして取引

データベースにおいてはマスタ管理がとても重要です。 都道府県マスタなどが分かり易いと思いますが、データ入力の候補群をマスタと呼びます。 データ入力の度に「東京都」「大阪府」とキーボードを打つのは面倒ですが、それ以上に問題となるのは誤入力の発生を許してしまうことです。 データの意味としては「東京」も「東京都」も同じですが、集計の条件として「東京都」を指定した場合には「東京」は含まれません。 「自民党」と入力する人がいて「自由民主党」と入力する人もいたのでは正確な集計が出来なくなります。 そのため入力候補として決まったデータ群はマスタ化しておき、そのリストから入力する仕組みを作るのが大切です。 リストから入力するのは便利ですが、ポイントは誤った情報が入力できないという点です。 取引先の社員名や顧客なども当然マスタ化する必要があります。 顧客名簿はきちんと管理されているのに、書籍を郵送する際の宛名ラベルの作成を間違えたということが無いように、宛名ラベル印刷と顧客管理は連動していることも重要です。 数量の項目は数字しか入力できない。 生年月日の空欄は許可しない。 年齢は生年月日から計算できるので入力しない。 などの条件を指定することで正確なデータしか入力できなくなります。 入力し易くなる上に、データの精度が上がる。 これこそがマスタ管理のメリットであり、データベース処理の特徴でもあります。 自分の仕事をよく見ればマスタ管理できそうなものは沢山あると思います。 即ちデータベース化した方が良いということです。 データベース化すれば発生した取引を１件ずつ入力する仕組みができあがるので、正確な

Firebase のデータベースでファイルの情報を管理！Firebase のストレージにブログの投稿を保存してブログのサービスの基本の準備ができました。更に使いやすいサービスにするために Firebase のデータベースの Cloud Firestore のデータベースに投稿の情報を入れておくと、より効率的に投稿の情報が取得できます。Firebase のストレージに保存したファイルからのデータの取得Markdown にブログの投稿のメタデータを埋め込んで置くと、そこから投稿の情報が取得できます。この情報を利用すれば、投稿の詳細を表示することが可能になります。しかし、この方法では情報を取得するには非常に手間がかかります。主な手順は以下の通りです。1. Firebase ストレージに保存されているファイル（フォルダ）の一覧を取得2. ファイル（フォルダ）の一覧を元にファイルの中身を取得3. ファイルの中身からファイルのメタデータ（ブログの情報）を取得というステップでブログのデータを取得します。問題は、実際にブログの投稿を表示しない場合でもファイルの中身を取得する必要があります。要は不要なアクセスが増える事になります。投稿時に必要なデータを取得しておく不要なアクセスを最小限にするために、ブログの原稿を投稿する際に Markdown のファイルに埋め込んだメタデータを取得して Firebase のデータベースである Cloud Firestore に情報を保存しておきます。 このようにする事で、ブログの原稿の情報は、Cloud Firestore から取得できるので、毎回投稿の原稿全体

Firebase ホスティングはプログラミングとの相性も抜群です！Firebase ホスティングは、LP との相性が良いことは既に紹介しましたが、勿論プログラミングとの相性も抜群です。Firebase の他の機能である、データベースやストレージと組み合わせて、React や Vue といったフロントエンドのフレームワークと組み合わせれば本格的な Web アプリケーションを短期間で開発する事が可能です。Firebase の他の機能との連携を考えると、一番相性が良いのは Web アプリケーションという事になります。React や Vue と連携する！React や Vue はフロントエンドのフレームワークと呼ばれる仕組みで、Web ブラウザで動作する UI などを作成するのに適した仕組みです。HTML/CSS と Javascript を組み合わせれば、特にフレームワークを利用しなくても Web アプリケーションを作成することは可能です。しかし、React や Vue などのフレームワークを利用すると、より効率的に UI を開発することができるので便利です。一方で、実際のデータなどの処理は Javascript で書くことになりますが、データを保存する必要がある場合は、通常は Web サーバー側で用意したデータベースなどを利用する必要があります。WordPress の場合は、Web サーバー側で、PHP のバックエンドサービスと、SQL データベースを利用してこうした機能を提供する仕組みになっています。Firebase を利用すると、こうしたバックエンドのサービスの機能やデータベー

私は医療機関で事務系の仕事をしています。 一時は収まっていたコロナ感染症患者の入院が再び始まりました。今回から少し複雑な統計をとる必要が発生したため、Accessで台帳作成に取り組んでいました。 大まかな構築は済んだのですが、レムデシビル（薬品名）を投与した患者を毎日カウントしていく必要がありました。電子カルテの集計から引っ張っても良いのですが、毎日集計処理をかけて台帳に入力していくのも手間がかかります。そこで薬剤部に相談してＡｃｃｅｓｓの台帳を共有し、レムデシビルを投与した患者にチェック☑をつけてもらうよう依頼しました。薬剤部では薬を準備する段階で患者情報を持っているため簡単な話でした。 このことについては快く承諾してもらえたのですが、逆に相談を受けることになりました。 Excelで一覧表作成聞けば、薬剤部では投与した患者のID、氏名、生年月日、性別、投与開始日等々をノートに書き込み、更にそれを最後にExcelに入力してメールで報告する業務があり、その手書き作業とExcel入力が非常に業務負担になっているというのです。 私の手元にはコロナ入院患者の一覧はあるが、レムデシビルを投与した患者を絞り込むのに手間がかかっている。 薬剤部ではレムデシビルを投与した患者の一覧があり、患者属性を手書きで書き加えてExcelへ入力している。 このように仕事が重複していることが分かりました。 そこで薬剤部のPC端末からAccess台帳を操作できるようにして、レムデシビル投与患者リストに属性を付加してExcelにエクスポートできるようにしました。 お互いが小一時間かけて作業していた仕事が、５分程

   プロダクトアウトとは、開発を行う上で、作り手の理想を優先させる方法のことです。利用者のニーズより「開発者がいいと思うものを作る」という考え方です。 　マーケットインとは、ニーズを優先し、利用者の視点を重視して開発を行い、提供していくことです。プロダクトアウトの対義語で「利用者が望むものを作る」という考え方です。 多くの職場には、専用領域のための管理ソフトが導入されていると思いますが、どこか使用感が窮屈だと感じることがあります。 既に書きましたが、どんな優秀なシステムエンジニアが作るシステムより、普段その仕事をしている人が幼稚なりにも作り上げたシステムの方が遥かに実用的なものが出来上がります。 だからこそ、Accessを利用できる環境があるのなら取り組まないのは勿体ないと思いませんか？ Accessで取り組める簡単な事例では、具体的にAccessでどのような仕事が処理できるかをご紹介します。 何かを管理する場合、対象物の詳細情報と全体の一覧リストが必要になります。 身近に感じて理解しやすいように、ドラッグストアを例に考えてみます。 お店では多くの商品を扱っているため、それらを一覧表で見られるようにする必要があります。また、商品の分類ごとに表示する方が機能的です。お店の天井から「化粧品」「医薬品」「キッチン」「食料品」・・・などプレートがぶら下げてあるのを見たことがあると思いますが、同じようにデータベースでも分類してあげます。 こうすることで、目的のデータを探しやすくなります。 他にも「男性向け」「女性向け」など、分類項目を増やせば、より管理がしやすくなります。 一覧でリスト

企業向けのデータベースはユーザー向けのインターフェイスすなわち入力用の画面と、データを蓄積、処理するサーバーを別々に管理、開発する必要があり非常に規模が大きく費用も高額です。 Accessは小規模ながらテーブル、フォーム、レポートをすべて処理してくれるため、単体でシステムを構築することができます。 大規模システムと比べられて酷評されることもあるAccessですが、規模に見合った使い方をすれば非常に強力なツールであることは間違いありません。 紙の時代とはいえ、Accessが利用できるからといって具体的にどんなことが出来るとか、今の業務がどう効率化されるかについてはピンとこない方も多いと思います。 私は医療従事者として仕事をしています。 医療現場は医師を中心として非常に多くの職業がチームとなって仕事をしています。今では電子カルテが当たり前になっており、補助者が素早く診療内容をキーボード入力しますが、ひと昔前は医師がすべて手書きしていたのです。 カルテに検査の内容を書き、検査依頼伝票を書き、処置依頼伝票を書き、やっと検査が実施されます。 今では事前にセット登録された検査項目をクリックするだけでおしまいです。 ２０分かかっていた仕事が１分もかからないようになりました。 その分患者さんを診る時間に費やせます。また多くの患者さんに対応することができます。 Excelを使い慣れた方は、Wordで表を作っている人を見て何でExcelでしないのだろうと不思議に思います。 しないのでは無く、知らないから他に選択肢がないのです。 （すべてでは無いですが）時間をかけてExcelシートを構築することより

2 つの Firebase セキュリティルールフロントエンドから Firebase のデータベースやストレージ機能を利用する場合、セキュリティルールの設定が必要になる場合が殆どです。セキュリティルールの設定は仕組みをよく理解していないと原因の特定に時間がかかる場合があります。基本は Firebase コンソールで設定Firebase のデータベースやストレージ機能を利用する場合、アクセスの権限はセキュリティルールを設定して管理します。Web 系のアプリの場合、Web ブラウザでフロントエンドのコードを実行するために、Javascript のソースコードを見ることができるため、プログラムのコードとは別にセキュリティ対策を行わないと問題になる場合が多いのが大きな理由です。通常設定は、Firebase のコンソールで行います。データベースやストレージの機能を有効にする際に設定することが求められるようになっています。開発時に最初から完全なセキュリティルールを設定するのは難しい場合も多いので、開発用の設定も準備されています。開発用の設定の場合、約 1 ヶ月先の日付を指定して、その期日前ならば全ての読み書きのアクセスの権限を許可して、基本機能の実装に集中することが可能なようにする事ができます。ただし、この開発用の設定の場合は、全ての権限が全ての利用者に与えられることになるので、注意しないとアプリの情報を改変されたりする可能性があります。従って、このモードで利用する場合は、インターネットに公開しないで、開発用の PC 上でテストをして利用する場合などに限定して利用するのが普通です。実際は、イ

Firebase データベースのコレクションのリストの取得Firebase のデータベースを利用する際、特にサブコレクションを作成する場合、コレクションのリストが欲しい場合があります。この Firebase のデーターベースのコレクションの作成はちょっと面倒です。この記事ではコレクションのリストの取得の方法を紹介します。面倒なコレクションの取得実は Firebase のデータベースのコレクションの取得はちょっと面倒です。通常の Firebase のフロントエンドのインターフェースでは、コレクションの一覧を取得する API はありません。従って、フロントエンドのみの実装ではデータ構造を工夫して、コレクションのリストを間接的に取得できるような仕組みを作って置くような工夫が必要です。取得できない情報を別の形でデータベースに保存しておくようにします。 こうすることで、Firebase の制限を超えた実装が可能になります。SDK による違いFirebase にはフロントエンドとバックエンドでは違ったインターフェースを持っています。 Web アプリなどでフロントエンドの Web ブラウザで実行するコードの場合は、CDN（Contents Delivary Network）を HTML の中で指定する形や、NPM などで Firebase のモジュールをインストールします。一方で、バックエンドで利用する場合には、「firebase admin SDK」を利用します。こちらの方は、いわゆる Node.js で利用するので、NPM で frebase admin SDK をインストールして利用し

経営管理について学ぶとMECE（ミーシー）という言葉がでてきます。 簡単に言えばモレがないこと、ダブリがないことですが、情報処理においては非常に大事なキーワードです。 だれかが作成した資料を別の人がPCに入力するようなことは避けたいところですが、実際には形を変えてよく起こっているのです。 では、どのように仕組みを変えていけば良いか、ですが「発生源入力」を考えることです。 発生した場所で、そこにいる人が入力するということです。 一度入力された情報は再度入力されることは無く、最後まで使用されます。 １度入力したデータは２度と入力しないこうすることで、物理的に「モレ」と「ダブリ」が排除されます。 シングルインプットと言われるものです。 医療業界ではミスが人的被害に直結するため、安全管理にシビアです。「人間は間違いを犯すもの」という前提に基づき、ミスを責めるのでは無く、いかにエラーが発生しない仕組みを作るかという部分に力を入れています。 Excelのような表計算ソフトは平面的にデータを扱うため、発生源入力には向いていません。顧客管理をする際に、１人のお客さんにSheetを１枚使うような設計ならできなくも無いですが、データの後利用が大変で逆に管理が難しくなります。 その点、Accessは立体的にデータを管理するため、１取引が１枚の伝票に集約されて効率的にデータを利用できます。 ほとんどの業界では、専用のシステムが稼働していると思います。 それらは非常に使いやすく便利にできていて、もはやシステム無しには仕事ができない程完成されていると思います。 Excelを工夫すれば真似できそうでしょ

   何より業務フローを一番理解した人がシステムを作成するのですから、非常にクオリティーの高いものが出来上がります。見た目は少々不格好でも処理するべき内容は本質を捉えていますから、便利なアプリケーションに仕上がるでしょう。 少しずつ改良を加えて機能的に満足いくものが出来上がる頃には、Accessのスキルもかなり上達していると思います。 そうすれば次の課題に取り掛かり、やがては身の回りの仕事をすべてシステム化できるようになっていると思います。 システム化をすると、不思議なことにAccessを操作する時間がどんどん増えてきます。 これはシステム化によって本来余分だった時間が削減されたためです。システムを作る時間は必要ですが、すぐに取り戻すことができます。なので、処理する仕事量は増えるにもかかわらず、時間はどんどん短縮されていくということが起こります。これは経験上の事実です。紙で書類を受け取り、台帳へ転記し、決定したら文書を発行し、処理が終わったら消し込む。これではいくら時間があっても処理に追われるばかりか、ミスを誘発するため業務フローに大きな問題があると考えられます。 モレやダブリが発生する要素が存在している限り良いシステムとは言えません。 私は事務系の医療従事者で、趣味を活かして色々なシステム作りに関わっています。 医療従事者向けの「医療従事者のためのAccess」というブログを書いているので、興味のある方は覗いてみてください。 自分でAccessのシステムを作ってみたいという方、完成まで責任をもってお手伝いしますので遠慮なくご連絡ください。Excelでの作業に煩雑さを感じたら

　Accessは本格的なリレーショナルデータベースとしての機能を持ちながら、高い汎用性で非常に多くのデスクワークを軽減してくれる優れたソフトウェアです。 MicroSoft365を利用されている方はAccessを利用することが出来ます。 折角利用できる環境にありながら使わないのは勿体ない話です。 　私はAccess単体を購入して使用していますが、MicroSoft365を使用した方が色々メリットが大きそうなので、次回から切り替えようと思っているところです。 また、職場のPCにAccessがインストールしてあればチャンスです。 多少バージョンが古くても2007以降であれば現在のAccessと互換性があるので問題ありません。 　自宅でAccessを勉強しようと思っても、なかなか進まない経験があるかもしれませんが、理由は簡単で必要に迫られていないからです。 職場であれば、細切れの隙間時間を利用して作業ができます。 Excelで煩わしさを感じている作業は、Accessへの置き換えを検討してみましょう。 ふとアイデアが湧いた時にすぐ作業できることも重要です。 私は事務系の医療従事者で、趣味を活かして色々なシステム作りに関わっています。医療従事者向けの「医療従事者のためのAccess」というブログを書いているので、興味のある方は覗いてみてください。自分でAccessのシステムを作ってみたいという方、完成まで責任をもってお手伝いしますので遠慮なくご連絡ください。

混在検索とは？「混在検索」というのは、こういう言葉がすでにあるのかどうかよく知らないで勝手につけた名前ですが・・・。簡単に言えば、レコードのフィールド数などの数やフォーマットが異なるデータを横断的に検索するものです。たとえば、各製品のデータに次のようなそれぞれ異なるフィールドがあるとします。製品A：製品ID,型番,年式,対応モデル,サイズ,・・・製品B：製品ID,容量,サイズ,重量,・・・製品C：製品ID,入力形状,出力形状,容量,年式,終了年・・・通常のサイトでは、次のようなパターンが多くなっています。（もちろん例外もあります）（１）検索システムがある場合は、ユーザーが製品A,製品B,製品Cのどれかを選ぶ→それぞれの中で製品IDを検索する。（２）検索システムがない場合は、製品A,製品B,製品CのそれぞれのカタログPDFが置いてあって、ユーザーがそれぞれ自分で見て、その製品IDの情報を目で追って探す。このようなときに、フィールド数などが異なるどの製品のIDであろうと一発で検索できるのを混在検索と呼んでいます。通常のDBシステムが入ったサイトでももちろんできますが、最初から計画していればともかく、後からこのような混在検索システムを入れるのはちょっと躊躇するかもしれません。簡単に混在検索システムを作る（完全一致検索）DataMarina+ToolBoxは弊社で自社開発したウェブ検索システムです。エクセルなどの表計算ソフトやパソコンDB、はたまたワードで作った表などのように１レコード１行のスタイルでできているデータの検索システムをウェブ上にDBシステムなしに実現するものです。今回は、

はじめに弊社で自社開発したウェブ上の検索技術であるDataMarina(データマリーナ)＋ToolBoxを使ったウェブアプリの開発方法を具体例を使って簡単に紹介します。題材は日本郵便が公開している郵便番号CSVファイル。これを使って、郵便番号・または住所から地図表示（グーグルマップ）のウェブアプリを作ってみます。検索方法の決定検索方法としては次の2通りを予定します。①郵便番号→地図②都道府県名→市町村→その下の町など、を絞り込んで→地図実際の作業(1)日本郵便からCSVファイルをダウンロード「郵便番号データダウンロード」で検索すれば出てきます。(2)CSVファイルの調整今回は、郵便番号と住所だけを使うので、読みなどのフィールドは削除して、文字コードをUTF-8に変換します。レコード数（行数）は12万4433あります。(3)検索方法に基づいて検索データを作成専用のツールを使って検索データを作成します。(4)検索用ホームページの作成簡単のために、すでにあるサンプルからページを拝借して文字を変更して再利用します。(5)ToolBox用の設定プログラム、ユーザープログラムの作成これももまた、すでにあるサンプルから拝借して文字・設定項目を変更して再利用します。ただ、地図の表示に関しては新規に機能を追加します。(6)アップロード以上ででき上がりです。ファイル一式をサーバーにアップロードしてアクセスします。機能の確認、必要であれば表示・スタイル等の修正を行って完了です。これで、約1時間でできました。もちろん、実際に使う場合にはページの新規作成、表示の調整などが必要になりますが、基本的にはこの

Firebase のデータベースアクセスFirebase のデータベースを利用する魅力の一つは、フロントエンド（Web ブラウザ）から直接アクセスできることがあります。一方で、バックエンドを実装すれば、バックエンドを経由したアクセスも可能です。では、どちらを利用するのが良いのかというと状況によって選択肢は変わってきます。この記事では、両方の利点と欠点をまとめて見ました。状況によって使い分けるコツとして活用ください。初心者にはどちらが良い？最初に考えるのは、Web 開発の初心者の場合です。 この場合は、迷わずにフロントエンドから直接利用する方法がおすすめです。 理由は簡単で、バックエンドを作る必要が無いからです。Firebase の利点を最大限に活用して、短時間でシンプルに実装するのが良いと思います。バックエンドの開発やデータベースの設定だけでも、初心者には大きな負担です。従って、フロントエンドの開発に集中できるのは Firebase を活用する大きな理由になります。では、この方法の欠点はなんでしょうか？細かいことを挙げれば色々あると思いますが、大きな欠点は 2 点です。＊　Firebase 以外のデータベースに移行するのが面倒＊　セキュリティルールの設定が必要　もう少し具体的に書くと、Firebase のデータベースをフロントエンドから直接呼び出しているので、Firebase 以外のデータベースを利用するには、フロントエンドのコードを基本的には全面的に書き直す必要があります。これが、大きな問題になるかと言うと殆どの場合は大きな問題では無い場合が多いかと思います。このモデルの場合

Firebase のデータベースの利用事例Firebase のデータベースの活用方法の一つを紹介します。 通常のデータベースとして利用する以外にも便利な利用方法があります。 それは、Firebase のデータベース（Cloude Firestore）は、高速にアクセスが可能というメリットがあります。 これを利用すると、Web アプリや Web サービスの価値を高める事が可能です。意外にアクセスに時間がかかる外部の Web サービスWeb アプリを開発する場合、全て自分で開発する場合もありますが、必要なサービスを自分のサービスに取り込んで利用する形で実装するケースも意外に多い物です。外部のサービスを取り込んで利用する例としては、＊　オンライン決済（PayPal や Stripe など）＊　メッセージの送信（MailChamp や SendGrid など）＊　Google の各種サービス（Map や Google Analytics など）などいろいろあります。機能的には、こうした外部のサービスがサポートしている API を利用すると、特に Firebase のデータベースを利用する必要はありません。しかし、実際にこうした外部のサービスを利用する場合の多くは、フロントエンド（Web ブラウザ）から直接アクセスするよりは、バックエンドを介して実装する仕組みになっている場合が多くなります。主な理由は、セキュリティです。外部のサービスが発行する秘密鍵（Private Key）を利用してアクセスする必要があるため、ソースコードが参照可能なフロントエンドのプログラムではなく、バックエンドでア

Firebase データベースの制限事項Firebase のデータベースは利用しやすく便利な仕組みですが、制限事項も幾つかあります。 この記事では、Firebase のデータベースの制限事項についてよく引っかかる項目を簡単にまとめてみました。複雑なクエリが書けないFirebase のデータベース（Firestore）は SQL データベースのように広く利用されているリレーショナル型のデータベースではありません。 リレーショナル形のデータベースの場合、複数のテーブルから必要なデータを持ってきて一つのテーブルのようにデータを取得するようなクエリも簡単に書くことができますが、Firebase のデータベース（Firestore）の場合は、こうした場合は複数のクエリを組み合わせてデータを取得して、プログラムでまとめるような処理が必要になります。この制限事項が問題になるかという点に関しては、実装の仕方（作り方）や方針によって変わってきます。 あまりケースとしては多くないと思いますが、リレーショナルベースを基にした設計を Firebase に置き換えたりする場合には、結構面倒になる場合が多くなります。この場合、SQL などで利用できるクエリを利用してデータベースにアクセスする場合が多いので Firebase でサポートしていないタイプのクエリがあるとその部分はプログラム（フロントエンド／バックエンド）で対応する必要があるので変更が必要になるためです。最初から Firebase のデータベース（Firestore）利用の前提で作る場合には、余り問題にならない場合が多いです。Firebase

Firebase が初心者に向いている理由は？Web 開発を行う場合、バックエンドのサービスやデータベースも必要になる事になる場合も多い物です。これまでの投稿で、バックエンドのサービスなどを使う場合はサーバーの選択も重要な要素だということも紹介してきました。そう考えると、Firebase を利用する事は初心者にとって大きなメリットがあります。データベースのアクセス自前でデータベースを用意して、バックエンドでアクセスする場合は、どの程度データベースの書き込みが集中するかを考慮する必要があります。当たり前ですが、「書き込み」はデータベースのデータを「変える」アクセスです。従って、同時に同じテーブルに各アクセスは制限されます。従って、短時間の間にデータベースに書き込めるアクセス数は限りがあります。従って、大量の同時書き込みが様相される場合は、実装の際には工夫が必要です。Firebase を利用する場合は、そうした「工夫」を Firebase 側でやってくれています。つまり、Firebase を利用して開発を行う場合、そうしたプログラミングからは直接見えない場所を余り気にする事なく、機能の実装に集中する事ができます。Firebase の場合、１秒間あたりの最大書き込み数は、10,000 ですこれはとても大きな値で、通常のアプリでは十分と言える性能です。バックエンドの実装Firebase でバックエンドの機能を実装する場合、「Functions」を利用する場合が多くなります。このバックエンドの Functions を動かすサーバーも Firebase の場合、十分な性能が確保されています

Django の便利な外部モジュール　 dj-database-urlDjango で利用できる便利なモジュールに「dj-database-url」があります。機能をちょっと見ただけだと余りメリットがないように見えますが、便利な外部モジュールです。特に、開発に「SQLite」を利用する場合は、インターネットに公開する際は別の SQL データベースに置き換えるケースが殆どです。こうした切り替えを上手く管理できるモジュールです。公開の際はデータベースを入れ替える場合が殆どです！前回も触れましたが、Django の開発時とインターネットに公開時では設定が違うのが普通です。 特にデータベースは、Web アプリや Web サービスの性能に影響する部分なので、公開時には MySQL や PostgreSQL など本格的な SQL データベースを使うのが普通です。 SQLite はデータベースと行っても一つのファイルにデータを保村する簡易的なデータベースなので、沢山の人が同時にアクセスするような使用は想定されていません。しかし、開発時は開発者以外のアクセスは基本的にないので、こうしたシンプルなデータベースで開発しても大きな問題ではありません。SQLite の場合、SQLiteBrowser など、データベースの中身をチェックできる便利なツールもあるので、開発時には便利です。先日紹介した、「django-configurations」で環境変数を使えばこの問題にも対処できますが、データベースの指定には、「dj-database-url」も便利です。dj-database-url を利用するには

Django で利用するデータベースDjango のフレームワークを利用して Web 開発をする場合は、SQL のデータベースを使うことになります。 SQL のデータベースは Firebase のデータベースとはちょっと違います。正確な言い方をすれば、Firebase のデータベースは広く活用されている、SQL などのリレーショナルデータベース（RDB)とは違うと言うことです。これまで、Firebase を中心にお届けしてきたので、その違いについてまとめて見ました。  Django は SQL データベースが基本Django で利用するデータベースは SQL データベースが基本です。標準では、SQLite を利用する設定になっています。SQLite を利用する場合は、特別な設定は必要ありません。そのまま、データベースの機能が利用可能です。その他にもメジャーな SQL のデータベースを利用可能です。Django の公式ページのドキュメントを見ると、公式にサポートされているデータベースは：＊　PostgreSQL＊　MariaDB＊　MySQL＊　Oracle＊　SQLite　です。この他に身もサードパーティがサポートしているデータベースに＊　CockroachDB＊　FIrebird＊　Microsoft SQL Server　　などがあります。利用するデータベースは、プロジェクトフォルダにある、settings.py で指定すれば利用可能です。標準設定では以下のようになっていますが、これを書き換えます。DATABASES = {    'default': {        '

Firebaseアプリのデータベースを管理するには？Firebase のデータベース機能（Cloud Firestore）を利用して作成したアプリの多くは、アプリで利用しているデータベースを管理する必要がある場合が多くなります。作成したアプリの一部として管理する方法もありますが、専用の管理アプリを作成するとセキュリティ上より安全に管理を行う事ができます。この記事では、Firebase のデータベースを管理する専用アプリを Firebase admin SDK を利用して行う方法を紹介します。Firebase データベースのセキュリティールールで管理者を設定できる一番手軽な方法は、作成するアプリの一部として、「管理者モード」を実装してしまう方法です。これは、管理者の Firebase のユーザー ID を特定して、そのユーザーに管理者の権限を設定する方法です。rules_version = '2';service cloud.firestore {  match /databases/{database}/documents {    match /{document=**} {      allow read, write: if request.auth.uid == "uid_for_admin";    }  }}　のようなセキュリティルールを設定すれば、特定のユーザー ID で Firebase のユーザー認証（ログイン）したユーザーは Firebase のデータベース（Cloud Firestore）の全てのコレクション／ドキュメントに対して、読み込みと書き込みができ

２つのFirebaseのアクセス方法　フロントエンドとバックエンドFirebase のデータベースを利用する場合、フロントエンドからアクセスする方法とバックエンドからアクセスする方法があります。手軽なのは、フロントエンドからアクセスする方法です。バックエンドサービスを作る必要がないので簡単に実装できるのは魅力です。一方で、アクセスの権限の細かい設定は、セキュリティルールで設定する必要があるので、複雑な権限やデータを扱う場合には面倒な点もあります。手軽に利用できるフロントエンドからのアクセス一番一般的でポピュラーな方法は Firebase のクライアント機能を利用する方法です。一番簡単な方法は、CDN（Contents Delivary Network）を利用する方法で、HTML で CDN のリンクを指定すれば、簡単に Firebase のデータベースにアクセスすることが可能です。テストモードならば簡単Firebase のデータベースは、Firebase のプロジェクトを作成して、データベースを作成する時に設定するようになっています。この時聞かれるのが、「プロダクションモード」と「テストモード」です。プロダクションモードは基本的にアクセスが禁止になっているので、必要に応じてセキュリティールールを設定してアクセスを許可していく必要があります。テストモードは基本的に全てのアクセスを許可しています。従って、誰でも全てのデータにアクセスできるのでインターネット上にサービスを公開する際には、セキュリティルールを設定して必要最低限のアクセスを許可するように変更する事は必須です。通常は、設定

Firebaseをどうして使うか？よく質問を頂くことに、「Firebase をどうして使うのか？」という事があります。 一言で答える場合は、「便利だから」というのが一番しっくりくる答えだと思います。 しかし、多くの方はそれでは何か納得できない場合が多いようです。そこで、この記事ではもう少し詳しく Firebase の何が便利なのかを考えてまとめて見ました。Firebase でアプリに必要な基本機能がまかなえるWeb アプリだけに限らずアプリを開発する上で必要な基本機能が揃っているのが一番便利な点です。この話は何度か書いていますが、基本的に、HTML/CSS がある程度書けて、Javascript の基本がわかれば、「本格的なアプリが作れる」というのは非常に魅力的です。１ヶ月勉強すれば Web アプリに必要な技術が身に付くどんなアプリを作るかのアイディアは必要ですが、アプリを作るために必要なスキルという見方をすれば、１ヶ月も真剣に勉強すれば必要なスキルを十分に身につける事ができます。つまり、本格的なアプリが１ヶ月で作れるようになるという事です。どれくらい凄いかと言うと、Firebase を使わない場合には、１ヶ月で作るのはかなり厳しいです。理由は、幾つかありますが、Firebase がやってくれる事を実現するのに他のことを勉強する必要があるからです。＊　データベース＊　バックエンドのプログラミング例えば、データベースに MySQL などの SQL データベースを準備して、バックエンドのプログラミングに PHP を使うとします。そうすると、SQL のデータベースについて勉強しなけれ

Firebaseのデータベースで何ができるか？Firebase は色々な機能を提供しています。その中でもよく使われる機能はログイン（ユーザー認証）とデータベースです。 データベースと言うと何か難しそうな気がしますが、基本はデータを置く場所です。データをどのように整理しておくかは工夫が必要ですが、インターネット上のデータを置く場所と考えるとわかりやすくなります。基本のデータの形は Javascript でよく利用されるデータ形式の JSON なので、Javascript のプログラムとは相性が良いので便利です。SQL との違いは？Web アプリや Web サービスと連携してよく利用されるデータベースに SQL があります。よく比較されますが、一般的なアプリやサービスでは SQL より扱いやすいデータベースです。SQL のデータの基本は「テーブル」です。イメージとしては誰もが利用したことがある表計算の表のイメージです。Microsoft の Excel が代表的なアプリですが、色々なデータをまとめるのに利用したことがある方は多いと思います。SQL のデータベースを利用する場合に必要なことは以下の通りです＊　表（テーブル）のフォーマットを決める＊　表（テーブル）をデータベース上に作成＊　表のデータを出し入れする記述（SQL）を書くSQL 自体はデータベース上のテーブルにデータを入れたり、読み出し、更新、削除をするための記述で厳密にはプログラムではありませんが、通常はプログラムからデータベースとデータのやりとりをする際に利用されます。テーブルに保存されるデータの各項目は予め決める必要が

Firebase Cloud Firestoreの管理ツールをNextJSで実装する（3）前回の投稿では、作成した NEXT のプロジェクトのテンプレートの API を呼び出すやり方を具体的な例を使って紹介しました。この記事では実際に Firebase のデータベースにアクセスする API を呼び出すやり方について紹介します。データベースの管理は基本的に以下の４つの機能があれば実現できます＊　既存のデータの取得＊　既存のデータの更新＊　既存のデータの削除＊　新規データの追加Cloud Firestore の既存のデータの取得Firebase の Cloud Firestore のデータの更新や削除を行う場合、最初に保存されているデータを取得して、そのデータをもとに処理するのが自然です。データベースのデータは、追加、更新、削除が発生するのが普通なので常に変わる可能性があります。したがって、あらかじめ表示するデータを準備しておくことはできません。基本は毎回データを Firebase Cloud Firestore から取得して表示する必要があります。NEXT の場合、サーバー側でレンダリングを行うので、ページをロードする前にデータを取得しておく必要があります。つまり、サーバー側で動的にページの表示データをレンダリングすることになります。これには「getServerSideProps()」という名前の関数を利用して取得します。export async function getServerSideProps(): Promise<any> {  const pendingl

Firebaseデータベース設計のコツは？Firebaseのデータベースは一般的によく利用されているデータベースのタイプとは違います。SQLなどのデータベースはリレーショナル型と呼ばれる物で、複数のテーブルを関連付けて使います。 ここでは、リレーショナル型データベースの詳しい話は省きますが、Firebaseの場合はCloud Firestoreは、JSONベースのデータベースでテーブルと似たような活用法もかの運ですが、全てのドキュメントのフィールドデータが同じである必要はありません。 従って、活用の仕方も変わってきますし、向いているアプリと、向いていないアプリも当然存在します。 Firebaseのデータベースが向いているアプリ Firebaseのデータベースは、複雑なデータ処理が要求されるようなアプリには余り向いていません。もう少し具体的にいえば、複数の関連するテーブルを使った複雑なクエリーでデータを検索したりする場合です。 こうした処理はリレーショナル型のデータベースが得意としている処理で、正規化された複数のテーブルを使ったクエリを使って必要な情報を取り出したりしたい場合には便利です。 Firebaseの場合は複数のコレクションからデータを抜き出したい場合には、複数のクエリーを使う必要がある場合がどうしても多くなります。これは、FirebaseのデータベースをアクセスするためのAPIの仕様が複数のコレクションに同時にアクセスする機能はサポートしていないので、一つ一つのコレクションから必要なデータを抜き出して利用する必要があるからです。 一つのテーブルで解決できるよう

FirebaseでSendGridを利用するSendGridというサービスをご存じですか？ SendGridはE-Mailを配信するためのサービスです。メルマガやニュースレターのように、登録したユーザーにメッセージを一括して配信したりすることができます。また、配信の日時を予め設定して配信したりする事もできます。 さらに、配送したメッセージのトラッキングなどの機能を提供しています。メッセージが届いたか、メッセージが開封されたかなどのイベントを追跡してマーケティングなどに役立てることもできます。 SendGridのサービスの利用方法 SendGrid自体も、Webサイトを提供していて、Webサイトから様々な設定やメッセージの配信が可能です。従って、特にプログラミングをしなくてもサービスを利用することができます。 サービスは無料から利用可能です。１日あたり１００通までのE-Mailの発想は無料プランで利用できます。（アメリカでSendGridが提供する無料プランの場合） 日本では、いくつかの代理店がSendGridのサービスを提供しています。構造計画研究所の提供するプランでは、月に１２，０００通までのE-Mailが無料となっています。（2020年11月現在） SendGridのサービスの仕組み SendGridのサービスは既存のE-Mailアドレスを使ってメッセージを配信するサービスです。SendGridがE-Mailアドレスを提供するわけではなく、すでに取得しているE-Mailアドレスを使って、SendGridの配信システムを使ってE-Mailを送るサービスです。つまり、

Firebaseデータベースでドキュメントごとにセキュリティルールを設定するFirebaseでデータベース（Cloud Firestore）を利用する場合、セキュリティルールの設定はとても大切です。 Firebaseコンソールでデータベース（Cloud Firestore）を作成した際に標準で設定されるルールはとてもシンプルなものです。実際の運用では、さらに細かいセキュリティルールが必要になる場合が殆どです。 コレクション毎のセキュリティルールの設定は比較的シンプルで分かりやすいので余り問題にならないと思いますが、ドキュメントごとにセキュリティルールを設定する場合は少し複雑になるのでなれないとルールの設定に時間を取られてしまう場合もあります。 この記事では、Firebaseの登録ユーザの拡張を考えた場合のセキュリティルールを例にセキュリティルールの設定の仕方を解説しています。 Firebaseが管理するユーザー情報 Firebaseでは、ユーザーの認証機能が用意されていてユーザーの管理や認証を簡単に実装することを可能にしています。 Firebaseから入手可能なユーザーの情報はE-Mailアドレスとパスワードの認証を理容師ている場合は次の様になります。 ＊　E-Mailアドレス(email) ＊　ユーザーＩＤ（uid） が基本的な情報です。これ以外の情報が必要な場合は、別にカスタムでテーブルを作って管理する必要があります。 グループごとにユーザーを管理することを考える 例えば、グループごとに管理者を置いてユーザーを管理することを考えます。 この場合は、Firebas

Reduxの代わりにFirebaseを使えるか？ReactでWebアプリやWebサービスを開発する場合、少し複雑なものになると色々な値の受け渡しも複雑になります。 そこで、データをまとめて管理するために、Reduxなどを利用する場合も多くなります。一方で、Reduxは慣れないと少しわかりにくい部分も多く、初心者にはハードルが高い場合もたくさんあります。 この記事では、FirebaseのデータベースをReduxの代わりに利用する可能性について考えてみました。 意外に高速なFirebaseのデータベースアクセス Reduxの代わりにFirebaseのデータベースにデータを置いて、データを一元管理することは技術的には可能です。当然、アクセスするスピードはReduxに置いた場合の方が高速なのは言うまでもありません。Firebaseのデータは基本的にFirebaseのサーバーに置かれていますのでデータの取得にはネットワークアクセスが必要です。当然、メモリにあるデータ（＝Reduxのデータ）の方が高速でアクセスできます。 しかし、Freibaseのデータベースアクセスは意外に高速です。以前、SendGridというE-Mailベースのメッセージ配信サービスのバックエンドの開発を受けて行いました。この時、最初の実装はフロントエンドからのリクエストをSendGridのサーバーに転送して、その応答をフロントエンドに返すという、仲介役の様な実装をしていました。しかし、実装を少し工夫して、FirebaseにSendGridの情報をコピーしておいてFirebaseを介してデータを取得するように変更