タグ

2017年3月11日のブックマーク (5件)

  • AWS Glue(分析用データ抽出、変換、ロード (ETL) )| AWS

    この図は、AWS Glue のユーザーが、複数のデータ統合エンジンを使用したジョブワークロードを作成するために、インターフェースオプションを選択する方法を示しています。左側に 1 つ、真ん中に 2 つ、右側に 1 つ、計 4 つのセクションを表示します。 左側の最初のセクションは、「データソース」と呼ばれています。 「Amazon S3」、「Amazon DynamoDB」、「Amazon EC2 上で実行するデータベース」、「データベース」および「SaaS」の、データソースが含まれます。 最初のセクションに、「インターフェースの選択」という図の上部にある真ん中のセクションを指す矢印があります。 この 2 番目のセクションには、3 つのセクションが含まれています。「AWS Glue Studio」、「Amazon SageMaker ノートブック」、「ノートブックと IDE」の 3 つです

    AWS Glue(分析用データ抽出、変換、ロード (ETL) )| AWS
    tofu-kun
    tofu-kun 2017/03/11
  • データベースアプリケーション開発を炎上させる負のスパイラル

    毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか? A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ

    データベースアプリケーション開発を炎上させる負のスパイラル
    tofu-kun
    tofu-kun 2017/03/11
  • DB論理設計のノウハウ - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? DB設計の概要を簡単におさらいした後、論理設計について主にまとめていきます。 DB設計の全体手順のおさらい DB設計は、大きく論理設計と物理設計に分けられます。 論理設計 概念スキーマを定義します。 エンティティの抽出 エンティティの定義 正規化 ER図の作成 物理設計 論理設計の結果を受けて、データを格納するための物理的な領域や格納方法を決めます。 テーブル定義 インデックス定義 ハードウェアのサイジング ストレージの冗長構成決定 ファイルの物理配置決定 テーブルの構成要素のおさらい 行と列 行(レコード):横のデータの組 列(カラム

    DB論理設計のノウハウ - Qiita
    tofu-kun
    tofu-kun 2017/03/11
  • 変更履歴を持つテーブルの設計 - Qiita

    ある日のできごと 少し前、「ブログの記事のようなものを、履歴を残しつつ編集できるようにするにはどのようなテーブル設計が良いか?」と尋ねられたことがありました. その時, まず思いついた(というか見聞きしたことがある方法)のは以下の様な2通りの方法だった. 記事テーブルにバージョン番号を持たせる方法 記事テーブルとは別に, だいたい同じ構造の履歴テーブルを持つ方法 こられの手法のメリット・デメリットについて, すこし考えていきたいと思います. その1 記事テーブルにバージョン番号を持たせる方法 概要 この方法では, 記事テーブルは一つだけ用意し, 更新される度に新しいレコードを追加していきます. 主キーはidとなるが, これはサロゲートキーで, 当の主キーは「記事グループid + verison」の複合主キーとなっています. 記事の最終更新日時は, 最新Versionのレコードのinser

    変更履歴を持つテーブルの設計 - Qiita
    tofu-kun
    tofu-kun 2017/03/11
  • DBのCRUDでUとDは必要ないという話を聞きましたが具体的にどう実装するの?

    "CRUD is Dead"なんて言われてる方もいらっしゃるようでCRUDのUとDを禁止する流れが存在するようです。 以下のようなサイトでも言われているように、CRUDのUとDを利用せずデータをログのように扱う方法は関連するデータ(特に履歴)が失われないために好感が持てました。 http://tanakakoichi9230.hatenablog.com/entry/6715376804 http://qiita.com/Jxck_/items/156d0a231c6968f2a474 http://mike-neck.hatenadiary.com/entry/2015/03/24/231422 現在MySQLを利用してウェブサービスを作成しようと考えているのですが、実際にUとDを利用しないDB設計をするにはどうすれば良いのかというところでつまづいてしまいました。 自分で考えたものは5つ

    DBのCRUDでUとDは必要ないという話を聞きましたが具体的にどう実装するの?
    tofu-kun
    tofu-kun 2017/03/11