すべてのカテゴリ

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

以前経理を担当していた時の話です。 医療機関では医薬品や医療機器をはじめ清掃や設備、事務用品に至るまで非常に多くの取引先があります。 月末締の請求書が届いたら翌月に支払いをするのですが、取引先によって２か月後支払いとか３か月後支払いなどと個別に支払いサイトを設けていました。 当時の上司は、数千万円の医薬品の支払いを先延ばすことで金利負担だけでも大分得しているんだと豪語していましたが、請求月と支払月が取引先ごとに異なるため管理が大変でした。 同じ月の請求書を２か月続けて振り込んだりして、期末の残高確認が合わず決算前に慌てたこともありました。 これを前任者から引き継いだ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という部品を差し込んで漢字を表示するのですが、その部品が５万円近くするのです。 最上位機種になると本体３０万円、モニタ２０万円、外付けディスク２０万円、ドットプリンタ２０万円、フルセットで１００万円近くしました。 私の月の小遣いが１０００円程度の頃です。そんな時代ですから、自由にパソコンを触れる環境というのは非常に魅力的でした。 では、パソコンで何をするかと言えば、主にはゲームなのですが既製品のゲームソフトは非常に高額なためとても小中学生に購入できるレベルではありません。 ではどうするか？というと、パソコン雑誌にプログラムが紹介してあるのでそれを自分たちで入力するのです。 機種別にプログラム言語

コンボボックスには「表示専用」パターンと「編集/保存」パターンがある目的はⅠ.値集合ソースの参照（レコードの表示）なのか　　　Ⅱ.値集合ソースの代入（レコードの上書き保存）なのか【例】図書館の利用者登録フォーム利用者の初回利用登録日に応じて利用期限を算出する必要があるためクエリに計算式を持たせ、フォームのレコードソースはクエリとしているⅠ. 照合が目的のフォーム     コンボボックスは、値集合ソースの参照（レコードの表示）のみレコードソースはクエリのまま各テキストボックスのコントロールソースに直接、column関数を書き込む利用者名∇=[cmb利用者].Column(1)誕生日∇=[cmb利用者].Column(2)住所∇=[cmb利用者].Column(3)登録日∇=[cmb利用者].Column(4)利用期限∇=[cmb利用者].Column(5)Ⅱ. 登録変更および新規登録が目的のフォームコンボボックスは、値集合ソースの代入（レコードの上書き保存）使用レコードソースをクエリからマスタテーブルに変更し各テキストボックスのコントロールソースからcolumn関数を消去テキストボックスがテーブルの項目と直接つながる（連結）必要があるため値集合ソースから選択した各フィールド名を各コントロールソースにセット※VBAが実行されれば、クエリを通じテーブルのレコードに計算結果が反映更新後処理の[イベント プロシージャ]にcolumn関数をVBA形式にて記入∇Private Sub cmb利用者_AfterUpdate()     Me!利用者名 = Me!cmb利用者.Column(1)

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）を利用してアクセスする必要があるため、ソースコードが参照可能なフロントエンドのプログラムではなく、バックエンドでア

【例】図書館の利用者登録フォーム学習メモ3-7では利用者の初回利用登録日に応じ、利用期限を算出した。しかし実際には運転免許等と同様、利用者の生年月日を基準に「初回登録年の○年後の誕生日まで」と定めているケースもある。実務上、個人情報が掲載されたテーブルと、その他の登録情報テーブルとは分けて管理したほうが望ましいケースもある。そこで、「利用者マスタ」テーブルの内、個人情報を利用者マスタに残し、図書館利用情報を示す「登録日」と「利用期限」を「図書利用券マスタ」として利用者マスタから切り離してみることを思いついた。両テーブルはクエリで結合させ、利用期限を算出し、フォームのレコードソースとすれば問題ないと考えた。利用期限は登録年の3年後の誕生日まで利用期限: DateSerial(Year([登録日]) + 3, Month([誕生日]), Day([誕生日]))しかし、さすがはガンコ爺Access（言い方！）テーブルを切り分けた以外はゆうべとまったく同じ設計なのに、微動だにしないではないか!!わたし遅くとも1時には寝たいのよ(੭ु(;・∀・))੭ु⁾⁾「連結列」：デフォルトは１だが、ソースであるクエリ構成上「図書利用券ID」が1列目。利用者IDの列を基準とする場合、2列目なので「2」とする必要があったみたい。「column関数」：レコードソースが変更され列数が変わったため、調整する必要がある。利用者名∇=[cmb利用者].Column(2)誕生日∇=[cmb利用者].Column(3)住所∇=[cmb利用者].Column(4)登録日∇=[cmb利用者].Column(5)利用期限∇

【例題】選択クエリの作成以下仕様に基づき、商品ごとの[理論在庫数](注)が[最小在庫数]を下回る商品を抽出のうえ、必要な[発注数量]・[仕入金額]を算出する選択クエリを作成しなさい。(1) クエリ名は『仕入先別発注対象商品』とすること。(2) 表示するフィールドは下記とすること。① [仕入先ＩＤ]② [仕入先名]③ [電話番号]④ [ＦＡＸ番号]⑤ [商品ＩＤ]⑥ [商品名]⑦ [仕入単価（税抜）]⑧ [最大在庫数]⑨ [最小在庫数]⑩ [理論在庫数]⑪ [発注数量]⑫ [仕入金額](3) [理論在庫数]のフィールドについては、下記の値を算出し設定すること。●下記（ア）から（イ）を減算した値（ア）「商品ＩＤ」ごとの「入出庫トラン」テーブル「入庫数」の合計値（イ）「商品ＩＤ」ごとの「入出庫トラン」テーブル「出庫数」の合計値(4) [発注数量]のフィールドについては、下記の値を算出し設定すること。●[最大在庫数]から、上記(3) [理論在庫数]を減算した値(5) [仕入金額]のフィールドについては、下記の値を算出し設定すること。●[仕入単価（税抜）]に、上記(4) [発注数量]を乗算した値(6) 抽出条件として、下記を設定すること。●上記(3)[理論在庫数]が、[最小在庫数]を下回るレコードのみ抽出(7) [仕入先ＩＤ]の昇順で、並び替えを設定すること。(8) クエリ内の各テーブル間に適切な結合および結合プロパティが設定されていること。学習メモ1-9.でひと通り作成「例題⑪：発注数量」演算で失敗【×】発注数量:Nz(Sum([最大在庫数]),0)　　　-(Nz(Sum([入庫数])

学習メモ4-1.において作成してみたレポート（見積書）たまたま明細が2ページ目に突入したことでレポートヘッダーに置くべき情報をページヘッダーに格納してたと気づけた理解が足りない(///∀///)Accessレポートの構造自分なりにまとめてみたまちがっているかもしれないけど① レポートヘッダー役割: 表紙/背表紙、まえがき配置：レポートの冒頭（1回だけ表示）② ページヘッダー役割: 見出し（ラベル）配置: 全ページ先頭（レポートヘッダーの次項目）③ グループヘッダー役割: 指定したフィールド単位におけるグループ化配置: グループ毎の先頭（ページヘッダーの次項目）④ 詳細セクション役割: 収納されたレコード全数分のデータ表示　　　セクション内のデータをレコードの数だけ繰り返し表示配置: レポートの中央（ヘッダーとフッターのあいだ）⑤ グループフッター役割: 指定したフィールド単位におけるグループごとの小計配置: グループ毎の末尾（詳細セクションの直下）⑥ ページフッター役割: ページ番号配置: 全ページ末尾　　　レポートフッターが用意されている場合、その下段に表示⑦ レポートフッター役割: 奥付け、あとがき、総計配置: レポートの最後（1回だけ表示）　　　ページフッターが用意されている場合、その上段に表示        

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

勤務先にてMicrosoft365を使用しており、ちびメカ自作のOutlookメール生成Accessアプリが月1回限定でこっそり活躍中。先日、もともと使用中の事業所マスタ(Accessフォーム)をコピーし、メール取引のない事業所用として別フォームを新たに設け、不要なレコードを削除。ななんと片方のフォームからも当該レコードがきれいに消失していた！肝を冷やした(ﾟдﾟlll)さいわいバックアップをとる習慣をつけているので、大事には至らなかったが、うかつだったと反省した。見た目は別々のフォームでも、同じテーブルを参照する以上、根っこは同じ。うっかり消してしまった場合もデータが保護されるよう、バックアップ用の作業テーブルを作っておくことを思いついた。バックアップ用テーブル運用の準備作業（私用ファイルで検証）① 元テーブルと同じ構成のバックアップ用テーブルを用意②「元のテーブル（配信テーブル）」にて、ユーザーが指定した話数レコードを「保存用テーブル（配信テーブル_バックアップ）」に移籍VBAによるINSERT → DELETE → RequeryPrivate Sub Cmd_削除_Click()　’エラーが発生したら、処理を中断して ErrHandlerラベル位置へジャンプ  On Error GoTo ErrHandler    Dim db As DAO.Database    Set db = CurrentDb         ' 指定したテーブル/フィールドのレコードを抽出し、保存用のバックアップテーブルへコピー開始    db.Execute _        "INSER

選択クエリのデザイングリッドに、アニメの「配信リスト」と「キャラクター名簿」をなんとなく置いて「クエリを実行」しただけで...Accessは「配信リスト：全111レコード」と「名簿：全20レコード」を掛け合わせた2,220行のレコードを表示させてくれる。「リレーションシップ（結合線）」を組んだわけでもなく、そのような命令式を書いたわけでもないのに、なぜなのか不思議。リレーションの話題になると、よく目にする「一対多（いち-たい-た）」テーブル同士において、1件のレコードに複数のレコードが結びつく様子を表現するらしいけど、日本語として不自然だしどちらが「多」なのか毎回こんがらがってしまう。でも、こういう場面に出会うとなんとなく腑に落ちる。配信リスト側が「一(一意)」、そこに群れるキャラ達が「多」で合ってる？人間の目では「これは配信リスト」「これは名簿」って各々のテーブルを独立した存在と理解する。でもAccessは違う。テーブル同士の関係性（ルール）に基づくデータ整理が目的のクエリデザイン画面に、命令をもたない双方が並ぶと、「とりあえず全ての組み合わせ（全パターン）を表示しとけば間違いないだろう！」と判断するのだろう。たまたま双方のテーブルに「Season」という共通フィールド。・「配信リスト」上のSeasonは、そのお話がどのSeasonに紐づくかを表示したもの・「名簿」上のSeasonは、そのキャラクターがどのSeasonから参加し始めたかを表示したものそれぞれ役割が異なる。ためしに「Season」同士をリレーションさせたが「名簿」マスタのSeason定義のあいまいさにより、実態

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

1. メインメニュー起動時プロパティシート選択の種類：フォームイベント：読み込み時Private Sub Form_Load()    MsgBox "図書館 貸出管理システムを起動します", vbInformation, "システム起動"End Sub時短コード°˖*✧◝(⁰▿⁰)◜✧*˖°Private Sub Form_Load()    MsgBox "起動します", 64End Sub2. 利用者登録フォームを開く（はい/いいえ確認あり）プロパティシート選択の種類：コマンドボタンイベント：クリック時Private Sub Cmd_利用者登録_Click() If MsgBox("利用者登録を確認しますか？", vbYesNo + vbQuestion) = vbYes Then    DoCmd.OpenForm "利用者登録" End IfEnd Sub時短コード°˖*✧◝(⁰▿⁰)◜✧*˖°Private Sub Cmd_利用者登録_Click() If MsgBox("開きますか？", 36) = 6 Then    DoCmd.OpenForm "利用者登録" End IfEnd Sub3. 貸出入力簿フォームを開く（はい/いいえ確認あり）プロパティシート選択の種類：コマンドボタンイベント：クリック時Private Sub Cmd_貸出入力簿_Click() If MsgBox("貸出入力簿を確認しますか？", vbYesNo + vbQuestion) = vbYes Then    DoCmd.OpenForm "貸出入力簿" End IfEnd Sub時

フォーム上で、貸出本の返却状況をチェックし=IIf(IsNull([返却日]),"未返却","返却済")=IIf(IsNull([返却日]),"要確認","貸出可能")クエリ上で、未返却(貸出中)冊数や返却済冊数を計上し貸出中冊数: Count(IIf(IsNull([返却日]),1,Null))　　⇅返却冊数: Count(IIf(IsNull([返却日]),Null,1))いかにもキチンと管理してます感のゴジ図書館だが、実のところ上記データは各書籍の所蔵(在庫)数には紐付けられてこなかった「本の在庫数に対し、何冊貸出中で何冊返却済か、利用者の貸出依頼を受付できる状況か否か」という、具体的な数の管理を一切おこなえていない人気ジャンルの統計など貸出実績の把握も重要だが、「持ち出し中の在庫品」管理は図書館の運営実務において最も注意を要求されるポイントに違いなく、役目を果たせなくてはデータベースの意味がないなので今回、貸出入力簿の情報を書籍マスタ上の所蔵数に紐付ける在庫計算を実装してみた貸出入力簿上で、貸出可能な数が揃わないと判断された時点で、貸出入力簿へ記入できなくなり、貸出受付をストップする仕組み@σ-σ) 1.貸出入力簿(メインフォーム)「在庫数」テキストボックス=IIf([所蔵数]-DCount("*","貸出トラン","[書籍ＩＤ]=" & [書籍ＩＤ] & " AND [返却日] Is Null")>0,"貸出可","在庫なし")@σ-σ) 2.貸出明細(サブフォーム)「挿入前処理」イベントプロシージャPrivate Sub Form_Before

＊°˖✧ゴジ図書館の貸出入力簿✧˖°＊なるべくラクに簡単に、最低限の機能だけ備えた設計を目指していて、なのにいつもめちゃ時間も気力も消耗してるけど、なんとか形にできた。メインもサブもコンボボックスもすべて揃えた。貸出日の14日後が返却期限:DateAdd("d",14,[貸出日])　〃　の1ヶ月後が返却期限:DateAdd("m",1,[貸出日])図書館を利用できるか利用可否: IIf([利用期限]<[貸出日],"利用不可","利用可能")貸出後の返却がなされているか返却状況：IIf(IsNull([返却日]),"未返却","返却済")本は貸出可能か貸出可否: IIf(IsNull([返却日]), "要確認", "貸出可能")

MicrosoftAccessを用いたデータベース作りの学習記録です既存データ検索フォームと、新規データ入力用フォームを同一ページ上に...メインフォームにコンボボックスを置き、新規入力はサブフォームでおこなわせる構成を組んだ。コンボボックスに謎が多すぎて前に進めず...一覧化して情報を整理。1年前から同じことで同じように悩み続ける自分。Accessは向いていないと実感する瞬間。

クエリの操作を覚え始めた頃から、謎で仕方なかった。デザイングリッドで必要なフィールドをちゃんと選択しているのに、いざクエリを実行すると、選択したはずのないフィールドが勝手についてくる。使用中のAccessファイルのみに適用できる設定方法いろいろ探して、プロパティシート上にある「全フィールド表示」初期設定の「はい」を「いいえ」にすれば、解決することを学習した。このプロパティシートを表示させるには、クエリ画面の背景であるグレー色の部分をあらかじめクリックしておく必要がある。（誤ってテーブルを選択した状態では、この設定項目を確認できない。）デフォルトのクエリをSQLビューで覗くと、SELECT＊とある。*（アスタリスク）はこの場合「全フィールドを引用しておくね」という意味で、それ前提に設計されている以上、ユーザーにはどうしようもない。SQLを自在に扱える上級者であれば、デザイングリッドを使うより自らコーディングして、その前提を覆す方が早いに違いない...か弱い初学者（当人比）にそんな余裕などあるはずもなく。Accessファイル全般に適用できる設定方法Microsoft公式による下記説明に辿り着いた。 ”「すべてのフィールドを出力する」オプションを選択すると、　クエリに Select * ステートメントが追加されます。” ”その後、そのステートメントは、特定のクエリの基になるテーブル　またはクエリ内のすべてのフィールドを取得します。”ttps://support.microsoft.com/ja-jp/access/customize-design-settings-for-objec

クエリを通してテーブルを学ぶ...選択クエリ作成問題で登場する式・発注数量 ＝ 最大在庫数（計）ｰ（出庫数（計）-入庫数（計））Accessの集計関数で表現すると、こうなるらしい。発注数量: [最大在庫数] - ( Nz(Sum([出庫数]),0) - Nz(Sum([入庫数]),0) )” Nz(Sum([]),0)”とは？トランザクションテーブルに対象レコードが1件も見当たらない場合、Sum() は合計値を出せず“結果なし（Null）”になる。その Null が式に混ざると計算結果を出せなくなるため、Null を0(ゼロ)に置き換える保険として Nz(Sum([ ]),0) が使われる。” Nz(Sum([]),0)”が最大在庫数には不要な理由商品マスタの「最大在庫数」は1商品につき1行だけ存在する固定値であり、設計上Nullになる恐れはない。データインポート用のExcelにも数字がしっかり入っており、Nz()不要。1商品につきデータ1件の構成なので、集計Sum() も必要ない。” Nz(Sum([]),0)”が必要なのはトランザクションテーブル上の「入庫数/出庫数」だけSum([出庫数]) ：出庫数の合計Sum([入庫数]) ：入庫数の合計Sum()は「対象レコードが1件もない」場合にNullを返す(計算できる材料が揃わないことにより算定結果を出せないと判断する)働きがある。対象レコードが 1 件以上 → 合計値（数値）を認める対象レコードが 0 件 → Nullを認める例：「商品マスタ」のある商品に対し、入出庫トラン上の入庫が1回も無い → Sum([入庫数]) = N

MicrosoftAccessを用いたデータベース作りの学習記録です通常、１から始まるオートナンバー型の数字を自由に指定する方法※レコード未入力のテーブルに限る

Accessファイルの正式納品を承ったら、ファイルの格納先として「信頼できる場所」を設定し(Access標準機能)、決められた場所に大切に格納していこうと決めた。 ファイル右クリック→プロパティ「セキュリティ...許可」の認証手順と同等の効果を得られる上に、外部ファイルと連携する機会が多くパス(保存場所)へ依存しやすいAccessの整理整頓にも役立つ。 手順：Accessを開く→ファイル→オプション→MicrosoftAccessトラストセンター→トラストセンターの設定(T)→信頼できる場所→新しい場所の追加(A)→パス参照(B)→OK

買い換えたPCにAccess2024をインストールし、ココナラで購入したAccessをUSB経由で移し替えたところ、新PCでファイルが使えない事態となった。 ココナラで初購入し、出品者から正式納品された段階のAccessファイル。 Accessタイトルバーには、データベースファイルのパス(保存場所)が表示される。使用環境への属性があり、受け取ったファイルをひとたび展開するだけで(Excelのようにデータを上書きしなくても)ファイル情報が更新される。 ココナラ上の取引において、データベース購入者としてはその特性が不安要素だったりする。正式納品を受け売買契約を終了した後、商品に心配な点が仮に見つかったとき、それが納品の時点から既にあったものなのか、こちらの使用状況に起因するものなのかぱっと見わかりにくい。 購入済み商品は購入履歴から遡れる。トークルーム利用中はもちろん、終了後も必要に応じダウンロードできる。 ただ購入者が手にできるのは厳密に言えば「成果物のコピー」であり、ダウンロードされた日時による新規データベースとしてPC上は認識される。 もちろん、中身までが更新されるわけではないからちゃんと状況は遡れるが、出品者へ問い合わせが必要な場合、できれば実際の納期に近い日時に形成された成果物を持参した方が説得力は増すだろう。 日常使い用とは別に、納品受理時点の成果物をちゃっかり保管している。 今回はそれが仇となった形。 Windowsにはセキュリティ対策として、ココナラのようなインターネットからダウンロードされたファイルに対し、Zone.Identifierとかいう出生地情報を紐づける

テーブルとは？：データ（レコード）の保管庫 ココナラのようなプラットフォーム上において、ユーザーが公開プロフィールに書き込んだ情報は会員情報としてマスタテーブルに登録される。多くの場合、会員番号以外はユーザー自身で自由に変更できる。 一方で、会員同士の商取引がメインの場合、日々更新される取引実績を格納するためのデータ保管場所も必要になる。そんなときに用いられるのが、トランザクションテーブル。Excelのようにすべてのデータを横並びに一覧表示させる方法もあるが、登録したすべての会員が商取引に参加するとは限らないため、会員名簿としてのマスタテーブルと活動記録のためのトランザクションテーブルという風に、目的ごとにテーブルを分けて効率よく管理を行うのが一般的。 それぞれのテーブルの共通項として、たとえば会員番号を配備することで、別々のテーブルで変更が行われても、お互いのテーブルに更新内容を紐づけ（リレーション）することが可能。プロフィール情報の変更や新たな商取引の追加にも混乱することなく、必要なときに関連項目を正しく結びつけ確認できる。 これこそAccessの持つリレーショナルの構造であり、得意分野らしい。 逆に言えば、1枚のシートで完結できるデータ整理にはExcelが向いている。 主キー&外部キー：結合された各々のテーブル上で果たす役割の違い 各テーブルの橋渡し役の「会員番号」は、会員名簿としてのマスタテーブル上では他の番号との重複が認められず、唯一無二かつ一度きりの登場。レコード情報を引率する主役であり「主キー」と呼ばれる。 一方、日々の商取引を記録するためのトランザクショ

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 から取得できるので、毎回投稿の原稿全体