すべてのカテゴリ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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）の全てのコレクション／ドキュメントに対して、読み込みと書き込みができ

Excelで介護支援記録管理システムを作ってみる～10日目多忙のため、再び間が開いてしまいました。 前回、パワークエリで作成したテーブルを直接加工して、特定の日付でフィルタリングしたデータを日誌に添付するための日誌シートを完成させました。 これと同様に、介護支援記録管理システムの一つの柱である動静記録を、入力済のデータから簡単にわかりやす作成できるようにします。 動静記録とは以前もふれたとおり、利用者の処遇内容を記した介護計画などを作成するさい必要となる文書で、基本的に前回の計画を策定した時点から、今回の策定に至るまでの記録データを時系列順に並べたものとなります。 従って、記録データからデータを抽出するための要素として、まず、特定の「利用者名」と期間（開始の「日付」と終了の「日付」）を必要としますが、他にも、利用者に何か事故や病変等が起きたとき、その後の対応がどうなっているか調べたいときに利用できるよう、「実施内容」でも追加的に絞り込みが行えるようにします。 まず、新たに「動静記録書」シートを作成します。このシート上に下の画像のとおり動静記録書のフォーマットを作りました。その上で、左上部に検索条件として、利用者名、期間を設定する開始日と終了日、そして実施内容を入力する部分を設けます。 一応、動静記録として表示させる記録データの数は20個までとしましたが、基本はそれぞれの施設の特性に合わせ、最大数を超えないよう設定します。 その上で、検索条件を入力する利用者名と実施内容のセルについては、データの入力規則を使い、記録テーブルに入力する方法と同様、リストから選べるよう設定します。 下

Excelで介護支援記録管理システムを作ってみる～4日目 前回までに、介護支援記録データのテーブルへデータを入力するさい、３つのフィールド（項目）である利用者名、実施内容、担当者名については、データの入力規則を用い、リストを使って入力することにしました。施設の規模から、このリストには最大で30行ほどが表示され、探しにくいという欠点はありますが、すべての項目を予め覚えておかなくても良いというメリットのほうを重視しました。 ただし、利用者、職員は利用の開始中止、退職や異動という理由で常に変化するため、これを考慮して入力規則の元となる範囲をしっかり定義しなくてはなりません。 なお、利用者、職員とも、別のExcelブックのワークシート上でテーブルで管理されているため、介護支援記録を管理するブックの中に、リンクしたテーブルの形でデータを取り込んでいます。リンク元テーブルに追加や削除などの変化があっても、このリンク先テーブルの更新を行うことで、最新情報がすぐに反映される仕組みです。 ちなみに、これらのテーブルは、介護支援記録管理システムの基礎を担う意味で、データベース用語で「マスタ」と呼ばれることもあります。前回の投稿では、データの入力規則によるリストの対象範囲を設定するさい、これらのテーブルにフィルターをかけ、該当するものだけ表示させてから設定したとしても、残念ながら無関係なデータも含めすべてリストに出てしまうことにふれました。 下の画像はその説明となりますが、左の図は利用者テーブルにフィルターをかけ、在籍が「利用中」の方に絞ったところ。右の図は記録テーブルにデータを入力するさい、利用者

Excelで介護支援記録管理システムを作ってみる～2日目 前回は、まずメインとなる介護支援記録データのテーブルを作成してみました。毎日の記録データの管理だけだったら、これで十分ではと考える方もいるかも知れません。ですが、入力のさい利用者全員の氏名を正確に覚えておくことは無理ですので、利用者の名簿を別に用意しておく必要があります。また実施内容の項目についても表記を取り決めておかないと、後で記録を検索しようとしたときに困ることとなります。 データベースシステムを構築する一番の目的は、各種情報を連携させ、スタッフ間の情報共有化と各種業務の効率化を図ることにありますから、記録データに関係する各種情報についてもデータベース化し、記録データとリンクしやすい形で管理できるようにすることが理想です。特に異動の多い利用者やスタッフの情報などがこれに該当するでしょう。 しかし実際のところ、一般的にこれらの情報は事業所内で別々に管理されているはずです。 例えば利用者の情報について言えば、氏名や年齢だけでなく、医療保険や介護保険の情報、家族の情報、年金や年収の情報など、サービスの供給や処遇、関係機関との連携に必要な様々な情報を、必要に応じ一括又は分割してデータとして管理しているのが普通です。 これらを全て一元的に管理するとなると、介護支援記録管理システムの範囲を超えてしまいます。 そこで、今回は、利用者の情報など関連する情報が別のExcelブックで管理されていることを前提に話を進めていくことにします。 まず利用者の情報は、利用者DBというExcelブックの中に、下の画像のような利用者テーブルで管理され

Accessのテーブルはこんな感じです。Excelのシートと変わりないですね。でもデータベースは、こんな感じの歯抜けを嫌います。空欄でも情報は情報なので、これだと「I0001のJANコードはNullですよ」ということになっています。Nullというのはなにもない、という意味なのですが、本当になにもないならなにもないはずです（よくわからない笑）。つまり枠をこしらえてしまうとそこにはなにかの情報を入れなくてはならず、Nullというのも立派な情報なので、本来I0001のJANコードは地球上に存在しないのにテーブル上ではI0001のJANコード＝Nullとなってしまうわけです。これはクエリを組む際など、いろいろ問題が出てきます。SQLも複雑になりますね。じゃあどうすりゃいいんだよ、という話ですね。こうします。たとえばI0001のJANコードを入力する場合は、縦に足します。これでJANコードのない商品には枠を設けずに済みます。空欄ができないので無駄なデータなし、速度と安定性も向上します。ただこの形式だと扱いづらいので、2つ上の画像みたいな作業用のテーブルを用意して、ふつう形式に変換するプログラムも合わせて用意します。もちろんぜんぶ必須項目ならふつう形式のテーブルで構わないのですが、なかなかそうはいかないですよね。Accessを学ばれている方は、こういう格納の仕方もあるんだよ、ということを覚えていただければと思います。変換プログラムはやや面倒なので、もし必要であれば安価でご提供いたしますよ～。

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

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

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

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

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

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

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

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

書類作成のための入力をデータベース化して活用できる一例ITのインフラが整った企業であれば、申請書類を手書きして担当者へ提出するような流れは無いのでしょうが、そうでなければ出張や休暇の申請書類を手書きで提出していると思います。私の職場もそうです。手書きでもWordや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 をインストールして利用し

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

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

Excelで介護支援記録管理システムを作ってみる～5日目前回の投稿では、配列数式を使いテーブルの中から必要とする複数のレコードを、順序良く一気に抜き出す方法を紹介しました。 改めて、介護支援記録管理システムの中で使うことができた配列数式を、下の画像のとおり実際に示しておきます。テーブルの「在籍」フィールドが"利用中"となっているレコードを抜き出す配列数式となりますが、指定範囲を列（フィールド）にしているため、今後テーブルにレコードがいくら追加されても問題はありません。これは構造化参照と呼ばれる方法で、データをテーブル化することで得られるメリットの一つです。但し、施設としての性格上、利用中の方が30名程度で今後も推移することを前提としています。では本題に進みましょう。 Excelでは、一つまたは複数のテーブルを元に、含まれるフィールド等を加工編集して、都合の良い別のテーブルを作り出すことができます。これがパワークエリ（Power Query）と呼ばれる機能です。 Excel 2016から標準機能として組み込まれており、比較的新しい機能であるため、入社してExcelを使い始めた若い方なら知っている方も多いのではないかと思いますが、古い人間の私は、名前を聞いたことはあっても、全く使う機会を持たないまま過ごしてきてしまいました。 シート上でのデータの切り貼りに余りに慣れ過ぎたため、非効率だと思っていても、そのやり方を続けたほうが、ある意味楽だったり、達成感を得られるせいでそれを続けてしまったわけです。これは誰しも陥りやすい陥穽と言えるでしょう。自分を例にして恐縮ですが、日本の生産性が低

ご覧いただきありがとうございます。今回はクエリについて書いてみようと思います。Accessには大きく分けて４つの機能があります。大雑把にはこんな感じです。①テーブルテーブルはデータを蓄積する基本的な部分で見た目はExcelシートに似ています。②クエリテーブルを基に集計や計算を実行します。クエリはテーブルを別な姿で表示しているだけなのでデータを持っている訳ではありません。クエリを削除してもデータは消えません。③フォームテーブルやクエリを基にデータを入力（表示）するためのインターフェイスです。見やすく操作しやすいフォームを作成することでデータ処理がより効率的になります。④レポートテーブルやクエリを基に印刷するためのデザインです。見やすいデザインで印刷されたレポートはそのまま現場で使用できる資料になります。PDFファイルで出力したりラベル、伝票を作成するのも簡単です。今回はデータベース処理の核心部分であるクエリについてご紹介してみましょう。私は医療機関で事務系の仕事をしている関係で、医療事務用のPC（医事コンと呼ばれるシステム）を操作してデータ出力や集計をおこなっています。特定の実績を抽出して件数を調べるような作業があるのですが、Excelで作業するには骨の折れる仕事なのです。（医療関係のデータベース構築であれば、実務的なものができると自負していますのでやってみたい！と思われる方は是非ご連絡ください）具体的なサンプルデータが無いので、今回はダミーデータでクエリの実例をご覧いただきたいと思います。まずWebサイトでダミーデータをダウンロードしてきます。「ダミーデータ」で検索すれば何件か

Excelで介護支援記録管理システムを作ってみる～1日目 Excelにおいてデータベースシステムの基礎となるのはテーブルです。 介護支援記録管理システムでは、文字通り介護支援記録のデータがメインとなりますので、「介護支援記録管理」と名付けたExcelブックを新規作成し、先頭シートに「記録データ」と名前を付け、その中にこのテーブルを作成することにしました。 前回のブログでふれたとおり、このデータは4W1Hの形式となり、入力項目（データベースではフィールドと呼びます）は、順に日付、利用者名、時刻、実施内容、実施記録、担当者の6項目としました。 なお、日付と時刻を分離し、その間に利用者名を入れたのには訳があり、同一日に同一利用者に対して複数の介護支援記録が入力されることを想定しています。これにより見た目がわかりやすくなります。 一応、各項目の説明については以下のとおりです。 ①日付:業務を実施した日付です。2024/5/1のように西暦表示で入力します。 ②利用者名:介護や支援を行った利用者の氏名を入力します。姓と名の間には1文字空白を入れます。 ③時刻:10:15のような表示で入力します。 ④実施内容:「食事介助」「排泄介助」のように端的に業務概要またはカテゴリーを表した内容を入力します。 ⑤実施記録:実施内容についての具体的な記述を入力します。⑥担当者:原則として介護支援業務を行った担当者の姓を入力します。さて、テーブルの作成にあたっては周囲に余白があったほうが見やすいため、シートのB2セルから列順に項目名を入力します。 そして入力した項目の範囲全体をドラッグしたあと、そのままホー

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に奪われてしまいました。このあたりは、経済的な成功体験とガラパゴスな技術に溺れて、世界標準から取り残されていく日本の姿を予兆していたのかも知れません。 ところが、実

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

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

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

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

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

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

あなたは補助金、助成金が世の中にどれくらいあるか知っていましたか？実は毎年公表される補助金と助成金は、日本全国で約2万件以上も存在しているのです。しかし、実際のところはどうでしょうか？ほとんどの方は「IT補助金」とか「リスキリング助成金」など、よく営業電話がかかってくるような数種類しか知らないのではないでしょうか？それもそのはず、経営者・事業主の皆様は日々忙しくて、そこまで情報収集できません。また補助金、助成金は中小企業診断士、社会保険労務士、公認会計士、税理士、行政書士といった人達も申請することが可能なのですが、それぞれ専門分野に特化していることが多く、約2万種類を網羅するのは非常に大変です。これを解決するには、常にリアルタイムで各省庁や全国各地の自治体などの最新情報を追い続けるシステムを持つしかありません。そのようなシステムがあれば、年間で数百件の助成金・補助金が、あなたの会社が使えるものとしてマッチングするのです。せっかくの制度、6％ではなく、もっともっと利用しませんか？

Excelで介護支援記録管理システムを作ってみる～10日目（つづき） 前回投稿の続きです。 動静記録を作成するさい必要な複数条件でのデータ抽出の準備が整いましたので、仕上げとして、動静記録書シートに抽出したデータを表示させてみます。 ここから先は前々回の「Excelで介護支援記録管理システムを作ってみる～9日目」で行ったやり方と同一です。 INDEX関数とSMALL関数を組み合わせ作成した配列数式を使う方法なのですが、Microsoft365やExcel2021以降をお使いの方はFILTER関数を使ってみてください。 この数式は、別シート上に作成した動静記録検索テーブルの[CK4]列の値、すなわち条件一致フラグの値が"1"であるデータを参照し、時系列順に表示させるものです。 下の画像のとおり、抽出させる条件として、利用者名を"柴田 徹子"、期間を"2024/5/10"～"2024/5/15"、実施内容は設定なしの条件設定としました。 データ表示部となる右下表のまず1行目、「日付」のセルにエラーを表示させないIFERROR関数でくるんだ数式を入力します。この数式に関する詳細を知りたい方は、少し以前の「Excelで...4日目」のブログをご覧ください。 数式を入力したら、配列数式となるようCtrlキーとShiftキーを押しながらEnterキーを押して確定します。すると、該当データの日付が表示されます。 同様に、利用者名、時刻、実施内容、実施記録、担当者の各列についても、動静記録検索テーブルの[CK4]列の値が"1"であるデータの当該項目が表示されるよう、配列数式を入力していきます。

Excelで介護支援記録管理システムを作ってみる～9日目 多忙だったため、だいぶ間が開いてしまいました。前回のブログでは、利用者に対する介護支援内容について、特定の日付で時系列順にまとめて日誌に添付するため、「日付」をキーとしてその日付の部分だけを抜き出す日誌シートを作りました。その上で、このシートに該当する日付のデータのみ表示させる目的で、パワークエリを使い記録テーブルを元にしたテーブル（「クエリテーブル」と呼ぶことにします）を作成し、それに「日付フラグ」を追加することを試みました。しかし、残念ながらそれはできない結果となりました。テーブルの外にあるセルの値を参照するという編集が無理だったからです。仕方ないので、取り敢えず新たな検索用データシート上に、パワークエリを使い、単に記録テーブルとリンクするだけの「検索用テーブル」を作るところまで進めたのが前回でした。そこで今回は、Power Query エディターは使わず、思い切って直接、検索用テーブルを加工し「日付フラグ」の追加を試みることにしました。 しかし、これには問題があります。 パワークエリで作成したクエリテーブルは、加工元のテーブルでデータの追加や修正を行った後、更新を行えば加工元と同じデータに書き換えられます。 この機能は非常に忠実で、例えばクエリテーブルを見やすくするため、一時的に一部の項目（列）を削除しても、更新を行うとその項目が再び復活して表示されます。これが嫌ならPower Query エディターでクエリテーブルを再編集するしかありません。 これと同様に、クエリテーブルにPower Query エディターは使わ

ココナラに出品中の介護支援記録管理システムについて、その開発経緯などを詳しく綴るブログを昨年10月から15回にわたり投稿してきましたが、3月の投稿で一応語り尽くした感があり、しばらくブログは休むことにしていました。そんな中、ブログの閲覧数の推移を眺めていたら、4回目に投稿した「Excelで介護支援記録管理システムは作れるか?」が突出して閲覧数が多く、しかも増え続けていることに気づきました。 標記の問いに対する答えとして『できなくはない』という結論を出しましたが、続く3回の投稿では、データベースを扱う場合のExcelの限界を指摘し、結局Accessでシステムを開発するに至った理由を語りました。 さらに、その後は本題のAccessによる開発の話に移行したのですが、閲覧数はあまり増えておらず、残念ながら関心は薄いようです。 確かに、一般のPCユーザーにとってAccessは殆んど馴染みがなく、使いこなすのは難しそうと感じている方が圧倒的なのでしょう。仕事の中でPCを使う多くの方の関心は、最もポピュラーで使いやすいExcelをどう活用できるかに向かっている、という事実をはっきり見せつけられた感じです。 それならばと思い、『できなくはない』と結論づけた以上、実際にExcelでシステムを作成する道順を公開していくことで、「データベースを仕事の中で活用したい」と考えている方々にとって少しでも参考になるのでは、と考えるに至りました。 前振りが長くなりましたが、今後のシリーズとして、私なりの方法でExcelを使い、介護支援記録管理システムを作成していく作業の過程をブログに投稿しながら、ついでにデー

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（識別コード）を送り込むようなケースです。関連づけられたデータに関する複数のフォームを並べて表示させるこ

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

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

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

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

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