タグ

設計に関するshige0216のブックマーク (6)

  • Efficient data transfer through zero copy

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    Efficient data transfer through zero copy
  • MS-Access2002 なりきりデータベース設計

    -「難しさ」について考える 「MS-Accessの中で、VBAを覚えることが一番難しい」と、言う人、いますよね。 決して間違った認識ではないと思います。 でも、このコーナーでお話することは、難しさの「度合い」が少々異なります。 VBAはあくまでも「データベースをより効率よく運用しより使いやすくするための手段」です。 「手段」の中には、そりゃ、難しいものもありますよ。VBAっつったって、決して簡単な言語ではありません。 構造はけっこう複雑です。理解するのは当に難しいと思います。 でも、でも、よく考えてみてください。 せっかくのVBAという言語、設計不足による欠陥住宅のひずみや隙間を埋めるための技術・・・に成り下がってしまってはいませんか? VBAとは、設計不足によるデータベースの不具合部分を埋めるためにぶん回すものではありません。 設計がシッカリできていて、自然に、しかるべきデータがたまる

  • リレーショナル・データベース設計入門

    データベース設計論(リレーショナル・データベース設計入門) 注記1: 以下の内容は、私が某大学で非常勤講師として、講義用に使用しているものです。 �@データベース設計にとって基的な概念では、3層スキーマ、データモデリング技法、関係モデル、データ正規化、 ERモデルがあります。 �ASQLの基的な文法、使い方、使用事例を具体的に述べてあります。 �Bデータベースの運用設計上で欠くことのできないデータベース制御(問合わせ処理、トランザクション処理、 同時実行制御、障害回復)について分かりやすい図解を交えて説明しております。 �Cオブジェクト指向データベース、分散データベースなどを含めて最近の技術動向にもふれておきます。 このテキストの内容を理解できれば、情報処理試験のうちデータベース領域の知識は十分身につくと思います。 注記2: 左側のアウトラインをクリックして検索を進めてく

  • 渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - HOME

    現在進行中のプロジェクトで、設計の品質や生産性を高めたい... 業務知識や上流工程のスキルを身につけてキャリアアップしたい... ――そのためのお役立ち情報を揃えています。実務家から高い評価を得ている設計手法、専用の支援ツール、洗練されたモデルライブラリー。これらを駆使して、効率的にシステム設計のレベルアップをはかりましょう。 ニュース 「CONCEPWARE/自治体」の開発が始まりました(080420) 「CONCEPWARE/販売管理」をバージョンアップしました(080404) 「CONCEPWARE/生産管理」をバージョンアップしました(080404) XEADで入出力パネルの画像ファイルを扱えるようになりました(071004) 管理人のブログ「設計者の発言」

  • 上流工程 : ITpro

    【自信が持てる見積もり技術】 世界最大のプロジェクトをこう見積もった  大規模,複雑,厳しい納期――。昨年秋に完全統合したJAL/JASの情報システム。成功を収めたプロジェクトの裏に,見積もり精度の高さがあった。プロジェクト・マネージャ(PM)を務めた岡村正司氏に,どのように見積もったのかを聞いた。 【だれも教えてくれなかった外部設計の「極意」】 データモデルの全体像を開発者と発注者が共有する 今回から「受発注システム」を想定して,データモデルを発注者と合意するためのコツを詳細に説明していきましょう。前回述べたように,データモデルは,発注者にとって難しいものです。 【図解で極める要求定義】 属人性の弊害解消に向けて プロセスと成果物の標準を定義  属人的なノウハウを,組織としてのノウハウに昇華しようという試みが始まっている。ヤフーもその1社。標準プロセスと成果物を定義する過程で,策定

  • システム設計 設計の考え方

    要件定義、基設計、詳細設計、プログラム設計、テスト、運用というシステム構築の手順が一般的に浸透しているが、このプロセスは 実践ではほとんど守られておらず、要件定義の中で、ユーザと一緒に一部分を掘り下げて行っているうちに混合されることが多い。 ここではその区別について考える。ただし、実践手順が多少、イレギュラーに設計されるのは全体の合理化を促進しようとするためであり、必ずしも良くないこととは言い切れない。 基的には必要とされるアクターを考えることが重要だと思われる。 外部設計(システム設計) =システム方式設計+ソフトウェア設計 内部設計           =コンポーネント設計 詳細設計            =プログラム設計                                       (IPA) 1.システム方式の決定:アーキテクチャーとして、H/

  • 1