「オブジェクト」を含む日記 RSS

はてなキーワード: オブジェクトとは

2019-02-23

{}

パイソン始めた

javaでいうmapのことディクショナリって言うらしい

jsだとオブジェクトだしやりたいこと同じだと思うんだけど名前バラバラ

リストはわりとリストな気がする

正直よく分かってないから間違ってたらつっこんでほしい

2019-02-20

メーカーSIer要求する単体テストが酷すぎる

メーカーSIer(仮にF社とする)のプロジェクトのもとで単体テスト工程に参画しているんだけど、非常につらいものがある。

テスト仕様書がつらい

エビデンスがつらい

障害報告がつらい


まとめ

この状況でテストする身にもなってくれよ...。

もう疲れた

anond:20190220100742

なんだろ。自分の中のボーダーラインとしては

ぷよぷよ2:スポーツとしてOK

スーパーマリオRTA:アスペ遊び

みたいな感覚がある。

マップオブジェクトとか物理挙動とかの可視化されてないデジタルになってる情報をどれだけ記憶しているか勝負どころになってる系はあんま好きじゃないしスポーツとしても妥当とは思わん。

参加者全員が覚えるべきルールとか情報は少なければ少ないほどいい。

2019-02-12

anond:20190212215020

あなたもひとりどうですか

酒池肉林ってなんか悍ましいかんじのオブジェクト想像してしまいません?火の鳥 宇宙編に出てくる植物人間の林みたいな

2019-02-03

anond:20190203181655

ヘローワールドを出力するプログラムを考えた時に、

オブジェクト指向ではない言語だと、

プリント『ヘローワールド』!」

の一行で済むじゃん?

それがオブジェクト指向になると・・・

1.プリンタブルオブジェクト継承し、プリント可能オブジェクトクラス定義する。

2.ニューコマンドにより、1のオブジェクト実体化する。

3.2で実体化したオブジェクトに対してプリントメソッドを実行する。

って書くじゃん?

すると、そのメソッドほにゃららなので実行できません。って言われるのがオチ



というのは冗談だけど、最低限の作法を知らないと動かせないのがオブジェクト指向欠点かなって思うよ。

人間、そういうどうでもいいところで躓く人が多い。

2019-02-02

anond:20190202000323

でも俺の知ってるCGよりずっと自然

まりロトスコープを使った作画は現状まだCG凌駕できるってこと?

人間すごいわ

この場合、凄いのは「現実」じゃね。

なんたって現実物理演算完璧だしオブジェクトが突き抜ける問題も一切起きない。

2019-01-31

この状態に対応するアニメーションはありますか?

男性に頼らない自立した自立した女性、活発に動く女性ヒーローアニメーション

サポートする男性キャラクターはありません、男性の影はありません

女の子が格闘して格好いいと思ってほしい(ドラゴンボールワンピースナルトセブンデッドリースポーオブジェクトなど)。

聖闘士星矢北斗の拳のようなもの世界のために戦うことが望ましい

男性視点が含まれているので、戦いの間に技術的な名前で話すことまたは精神叫び声を得ることは不可能です。 例えば、キラキラ文庫は良くありません。

・愛の要素はありません。 愛至上主義がなくても

男性女性女の子はいません。

大人の女性が見て楽しむことができます

・かなり治療法のような女の子にとっては「女性のため」ではないのでそうではありません。 大人のための高いターゲット商品のための数字はそこにあります男性ファンによって見るアニメ

・主なターゲットレイヤ男性ではありません。 「女性を楽しむことができる男性のための」アニメーションはよくありません。

男性作家男性作家など男性視点入力されていない "女性を考える女性のための女性主人公"はよくありません。 男性による女性主人公思想名誉ある男性ヒーローだろうから、そうしないでください。

・・たとえば、Ke! 女は部長シリーズ作曲キャラクターデザイン、作画部長、主役に任命され、ストーリーボードストーリーには女もいるが原作者男性、主視聴者男性

萌え絵ダメです。 "萌え"の基準は、空の境界約束のネバーランドウィザードの妻、バイオレットエバーガーデン、キノの旅リトルウィッチアカデミアOKです。 まどかひだまりスケッチラブライブ! NGです

セクシースタイルは、Bayonettaのように見えますキラーキルは大丈夫です

攻撃巨人ミカサのような準主人公は許されない

・「少女戦」のようなタイトルが悪くなるのは良くありません。 中身だからダメ

集団的イメージプレイ女性主題ではないので、それは良くありません。 PSYCHO - PASSは良くありません。 明らかに女性英雄が優れています

魔法少女趣味ではないので、しないでください(CCサクラセーラームーンなど)

・それは深夜のバンド放送ではない、それは大衆を受け取った主要な作品であるべきです

・それは見ているように感じるには長すぎるので2つ以上のコースを持つには長すぎるように思われるのでショートはより良いです

理想バイオハザードクレアRDGレッドデータガールスピリットガーディアンチハヤフル、攻殻機動隊パトレイバー

該当する場合マンガ小説ゲーム問題ありません。 Animation博士増田氏がしばらく出てきているとしたら?

(その他の注意事項)

Originは「ドラマには女性ヒーローがたくさんいるがアニメには数少ない」と言っていて問題があるようで、実写のコンテンツは除外

・「現在配給されているアニメには女性主人公ほとんどいない」というのは問題なので、古すぎるのはよくありません

・「さて、あなたがそれを作ろうとするなら」は「そのような作品ほとんどないので、それは問題となるコメントです、それであなた自分でそれを議論することができるだけであるようにすることができます

(付記2)

@矛盾質問内の理想的な作業最初に条件から外れていることを確認してください、@ quzi23してください。 この人の発言から条件を抽出して要約したところです。

2019-01-30

anond:20190130113420

それ構造体でも連想配列でもいいじゃねーか

なんでオブジェクト必要なんだ

とは考えなかったんだろな

2019-01-27

anond:20190127224821

SV

I laughed.

me.laugh()

疑問の余地がなく正しいと思う。

SVO

I have a pen.

me.has(new Pen())

「所有している」はメソッドでは表現できないと思う。

meオブジェクトメンバーpenがいる、とUMLかなんかで表現するしかなさそう。

SVC

It's a pen.

it.isA(Pen)

It is a Pen継承関係表現する?

He looks happy.

him.looks(Feeling.HAPPY)

him.looks()をコールしたらFeeling.HAPPYが返ってくる方が正確?

でも人によって感じ方違うしな・・・

SVOO

I gave my brother a chocolate

me.gives(me.brother, new Chocolate())

難しい。合ってると思う。

SVOC

I made my brother my wife

me.makes(me.brother, new Wife(me))

難しい。

that

which (非制限用法)

読めない(´・ω・`)

2019-01-18

大規模SI自分マッチしない理由

そもそもITゼネコン主導の大規模開発は悪評まみれで、天国案件なんて数えるほどしかないと言われる。

なので誰がやってもしんどいと思うが、特に自分には全く合わなかった。


自分プログラミングは、動かす前に「これで行けるだろう」と確信しながら、動かしてみて抜けや漏れが発覚するタイプなので、コード品質は多分悪い部類に入るだろう。

つーか、仕事なんて楽に済ませたいから、コードなんて可能な限り書きたくないというのが一番にある、かなり独善的人間だ。


一方で大規模SIプログラマなんて、基本的ライン工か調整役以外お呼びでない。

そしてコミュ障でもある自分必然的に、もらった設計書の長ーいフローをひたすらコード翻訳するという、まさにライン工として身を粉にして働くしかなかった。

それこそif文の後のelseが何ページも先になろうが、ループが何重にネストしようが一切気にせず、可能な限り設計に沿うようコードを書き続けた。

元々コードを書かずに済ませたい自分には、正直目が眩みそうな作業だったが仕方ない。

しかし上述のように元来不注意な人間なので、品質は恐らくメンバーの中では最低レベルの代物を量産する結果となった。


でも、本当にしんどかったのはテストである

コーディングスケジュール的に余裕なかったが、テストに至っては必死にというか、死に物狂いで頑張らないと遅れてしまうくらい、作業量が半端なかった。

ちょっと込み入ったメソッドになると、それだけでテストケースが20とか30とか相当な数になるので、ケースの抽出から始まって、最終的にレポートにまとめてカバレッジと一緒に提出するまで、地獄のような作業連続になった。


最終的には体調不良理由に「すんませんクビにしてください」と言って現場を抜け、その責任を取って僻地に飛ばされ今に至る。

そんなことはどうでもいいのだが、それ以来、テスト自動化ツールに対しては、理屈抜きに憎しみしか沸かないようになった。

フレームワークの便利さを推す記事とか、むやみに持ち上げるヤツは一切信用できなくなったし、オブジェクト志向をやたら崇高で革命的なもののように吹聴するやつはもっと信用できなくなった。

そんなもの自分にとって、楽に仕事をする味方にならないものであることがハッキリしたからというのが理由である

2019-01-12

都民が冷たい理由知ってるか?

満員電車、3時間待ちのスイーツ店、どこかしこでやってるイベント

人の多いところで育って、毎日人を景色と捉える訓練してるから

駅のホーム。隣で立ってるあの人はただのオブジェクト

2019-01-09

anond:20190109094921

一番妥当性が高いのは基底オブジェクトの == あたりをオーバーライドすることだけどな…

2019-01-03

新年早々に怒られた

「そのムーブ全然だめ」

もっとオブジェクトに絡め」

「それナーフされた」

キャリーされすぎ」


ルーに影響されすぎだろJK

まんじむかついた

ハァー・・・

2018-12-29

anond:20181229113056

データストレージ

2ch(5ch)は、過去ログファイル形式で保存している。

ファイル形式にすると、性能がOSファイルシステムに依存してしまうことになる。

オブジェクトストレージを導入して、ファイルシステムに依存しない方がいいね

検索用にはRDB+Elasticsearchにもコピーを入れておけばいいのかな?

2018-12-26

気体が壁にぶつかる時とか現実にはどう考えても均一じゃないしランダム要素を加えるしかないと思うんだけど

そういうとこの乱数制御コードとか現実と同じように書けるの?

ゲームオブジェクトなら別に均一ってことにしても誰も困らないけど

anond:20181226101524

そもそもオタクって名乗ってもいない奴じゃねーか?それ

オタクガー」って言ってる人のオタク認識ガバガバ過ぎてオブジェクトふわふわしすぎ

2018-12-04

増田プログラマー養成講座 その23 SQLを巡る物語

前回は、データベース設計について学びました。

今回は、その他のデータベース話題について見てみましょう。

 

 

リレーショナル・データベース理論

問合型言語SQLは、「関係代数」という計算モデルを基に作られたプログラミング言語

一度「関係代数」について学んでおくと、RDBの使い方について、理解が深まる。

↑このスライド作者さんは他にもDB関係資料作成されてるので見ておくといいかも?

 

 

SQL以外の問合型言語

SQL以外にも「SPARQL」、「TMQL」(Topic Maps Query Language)等、いろいろな問合型言語がある。

実際に使う機会は少ないかもしれないが、「問い合わせ」で処理するという発想は参考になるかも?

 

Datalog

Datalogは「Prolog」(論理言語)を源流にもつ宣言的なデータベース問合せ言語。DatalogはSQLと同等の表現力を持つ。

Datalogは様々なプログラミング言語で利用できる。

 

トピックマップ

トピックマップ」は、本の索引もっと機能にしたような仕組みで、RDBとは違う形でデータを蓄積/検索できる。

 

 

RDB以外のデータベース

SQLを使わないデータベースもある。

 

NoSQL

NoSQL一般に "Not only SQL" と解釈される)とは、関係データベース管理システム (RDBMS) 以外のデータベース管理システムを指すおおまかな分類語である

関係モデルではないデータストアの特徴として、固定されたスキーマに縛られないこと、関係モデルの結合操作を利用しないこと(場合によっては単にそのような機能が欠落しているだけ)、水平スケーラビティが確保しやすい事が多いこと、トランザクションを利用できないものが多いことなどが挙げられる。

学術的な世界では、この種のデータベースのことを構造ストレージ (structured storage) と呼ぶことが多い。

 

NoSQLデータベースは、関係データベースのような汎用性は欠くものの、その制約された条件下ではRDBMSより高いパフォーマンスを持つ。

そのためビッグデータソリューションでしばしば活用される。

NoSQLデータベース管理システム有用な場面は、関係モデル必要としないデータを扱う時や、大量のデータを扱う時である

 

有名な実装として、GoogleBigTableアマゾンAmazon DynamoDBなどがある。オープンソース実装も数多く存在し、例えばMongoDBRedisApache HBase、HyperTable, Apache Cassandraなどがある。

 

 

SQLRDBに慣れたら、NoSQLも調べてみよう!

 

 

その他、データベース関係話題

DB運用管理で学んでおきたい話題を列挙してみよう。

 

 

SQL開発物語

問合型言語学習最後に、SQLを巡る物語も見てみよう。(SQL学習ドラマチックで楽しいものにしたいねw)

 

 

RDB活用すれば、大量のデータを処理して、多くの仕事効率化できる。(金持ちへの扉が開かれる。)

暇があったら、SQL物語登場人物も見ておこう。

 

エドガーフランク・コッド(Edgar Frank "Ted" Codd, 1923年8月23日 - 2003年4月18日)は、イングランドまれ計算機科学者

関係データベース理論的基盤であるデータベース管理関係モデル発明した。

 

1960年代から1970年代、コッドはデータ配置に関する理論を構築し、1970年 "A Relational Model of Data for Large Shared Data Banks" (大規模共有データバンクのデータ関係モデル)という論文を発表した(IBM内ではその1年前に公表している)。

しかし、IBMライバルがそれを実装し始めるまで彼の提案を実行に移そうとせず、コッドは失望した。

当初、IBMはIMS/DB収益を守るため、関係モデル実装することを拒んだ。

コッドはIBM顧客自身モデル実装した場合可能性を提示し、顧客からIBM圧力をかけさせた。

そこでIBM関係モデル実装を開発する System R プロジェクトを Future Systems プロジェクトに含める形で立ち上げたが、その開発チームとコッドは分離され、しかもコッドの理論精通した者はチーム内にいなかった。

結果として彼らはコッドの Alpha 言語を使わずリレーショナルでないSEQUEL言語を開発した。

 

ラリーエリソンSEQUEL 完成前に発表された論文に基づいて Oracle を完成させ、先に発売している。

IBMは、SQL/DS を発売した。

幹部技術音痴だと、部下の名案も却下してしまうんですね?

 

ローレンス・ジョセフ・エリソン(Lawrence Joseph Ellison、1944年8月17日 - )は、データベースソフトをはじめとする大手ビジネスソフトウェア企業オラクルコーポレーションの共同設立者であり、元CEO会長CTOである

2014年現在総資産は500億ドルで、世界で5番目の富豪である

 

ニューヨーク出身アシュケナジムユダヤ人母親フローレンススペルマン(Florence Spellman)は出産当時未婚の19歳で、生後9ヶ月のラリーシカゴに住む叔母リリアンエリソンとその夫である義理叔父ルイスエリソン養子として引き取ってもらった。ラリーは実の母の名も知らず育ったが、48歳の時に初めて対面した。

 

高校時代秀才だが、無愛想な生徒だった。イリノイ大学アーバナシャンペーン校に二年生まで通っていたが、リリアンの死後まもなく退学。カリフォルニア州北部で夏を過ごした後、シカゴ大学で学ぶために実家に戻ったものの三ヶ月でまたも退学し、カリフォルニア移住。この頃、コンピュータに触れ始めている。

 

1970年代エリソンはアンペックスで働いた。彼の関わったプロジェクトのひとつCIA向けデータベース開発があり、彼はそれに「オラクル (Oracle)」と名づけた。

エリソンエドガー・F・コッドのリレーショナルデータベースシステムに関する論文 A Relational Model of Data for Large Shared Data Banks に触発され、1977年自己資金1400ドルオラクル設立した。

彼はIBMのSystem Rデータベースがコッドの理論に基づいたものであると聞き、Oracleもこれと互換性のある製品にしたかったのだが、IBMエラーコード秘密にすることによって互換製品が出てくるのを防いでいた。

オラクル最初製品Oracle 2であり、Oracle 1は存在しない。このリリース番号は、それ以前のバージョンバグが全て解決されていることを暗示しようとして付けられた。

 

1997年8月ラリーエリソン親友スティーブ・ジョブズアップルに戻った後、同社の取締役就任した。2002年9月20日取締役会に出席する時間が充分に取れないことを理由アップル取締役を辞任した。

この人、キャラクター的にはあまりきじゃないけど、行動力はすごいね

コッド博士論文を見て自分RDBを作っちゃった!

Oracleバージョンを「2」から始めて、改良されているように見せかける。~ちょっと詐欺っぽいけど、商売うまい?w

 

 

 

SQLデータベース活用して、素敵なアプリWebサービスを開発してください。

では、これでいったん、増田プログラマー養成講座を終了します。

御清聴いただき、どうもありがとうございました。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラム=データ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミングの練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181026145516 増田プログラマー養成講座 その12 データベース参考書

anond:20181028152656 増田プログラマー養成講座 その13 SQL文法

anond:20181031014212 増田プログラマー養成講座 その14 Webアプリの試作品作成

anond:20181101225335 増田プログラマー養成講座 その15 Webアプリの完成見本

anond:20181101230220 増田プログラマー養成講座 その16 Webアプリの完成見本(続き)

anond:20181104161900 増田プログラマー養成講座 その17 Webアプリの骨組み

anond:20181104233013 増田プログラマー養成講座 その18 SQLデータの追加と取得

anond:20181110120715 増田プログラマー養成講座 その19 SQLデータ更新

anond:20181110182445 増田プログラマー養成講座 その20 SQLデータの削除

anond:20181111205255 増田プログラマー養成講座 その21 データベース設計 (1)要件定義

anond:20181119224031 増田プログラマー養成講座 その22 データベース設計 概念物理

anond:20181204142213 増田プログラマー養成講座 その23 SQLを巡る物語 ←★今ここ★

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-11-26

昔のアニメを見返してて思ったけどやっぱりアニメアナログだね

と言っても理由はよく言われるようなセルの質感がとか作画力がなんて話ではなく

レンズなんだよね

例え元がセルに描かれた絵でも本物のレンズを通して撮影されたものというだけでやっぱり空気感が違う

セルの手前にある数センチ空気層だけはまごうことなき実写だから

 

思えば3Dアニメオブジェクトを表示するのがやっとだった頃から

今ではレンズ空気シミュレーションが出来てきてリアルになった一方で

2Dは逆にいかアナログの「ノイズ」を消して

純度100%の精彩なイラストを表示するかに苦心してきてしまったような気がする

 

エフェクトでどうとでもなる問題な気もするけど

しろこっちこそが今のアニメファンの求めるものなのかも知れないし

どうしようもないのかも知れないな

残念だ

2018-11-21

anond:20181121144201

ワードエクセル3Dオブジェクトやら動画やらを貼り付けたら、

その再生時にGPUがあると快適になることもある。

とはいえインテルオンボードGPUでも最近は頑張ってるので、

ムリしてつける必要はないだろう。

ゲームをしなくても、Photoshop画像加工とかしたり、イラレデカファイル編集するなら

グラボ絶対あったほうがいい。

2018-11-20

[] #65-3「短くて長い一日」

まさかドタキャンじゃないよな。

今回は俺も一応モチベーションがあったのに、ここにきてそれが減少していくのを感じる。

これは、アレだ。

大した理由もないのに、無性に学校行きたくない時のヤツだ。

どうする。

から弟を迎えに行けば間に合うか。

いや、いま向かっている途中ですれ違ったらどうする。

もう今回の小旅行を断ったほうがいいだろうか。

ああ、くそ

寝起きの頭じゃあ考えがまとまらない。

「ごめん、にい……兄貴。遅くなった」

頭がグズりだしてきたとき、弟がやっと来てくれた。

それで失ったモチベーションが元通りになるほど俺は調子のいい人間ではないが、ひとまず安心といったところか。

「弟よお、荷物もないのに何をそんな時間をかけることがあるんだ」

「い……いやあ、寝癖が大暴れしてさあ」

「寝癖って。お前そういうの気にするタイプじゃないだろう」

「そ、そうかな……」

遅刻してきたのはともかく、何だか弟の様子がおかしい。

しかし、このときの俺は寝起きで判断力が鈍っていて、そのことを深く考えていなかったんだ。

「じゃあ集まったところで、別次元での行動についておさらいするよ」

ガイドが注意事項を説明し始めるが、内容はほとんど当然のことばかりだ。

次元に悪影響を与えないために目立つようなことはしないだとか、その次元の住人に迷惑をかけないようにだとか。

ところどころ小難しい横文字を並べている以外は、修学旅行学生しおりレベルのことしか言っていない。

「……というわけで、キミたちが注意すべきなのはそんなところかな。ちゃんと心がけてね」

「は~い」

からといって、本当に修学旅行中の生徒みたいな気のない返事をしてしまう弟も大概だが。

言ってからそのことに気づいたようで、気まずそうにモジモジしている。

こいつ、まだ寝ぼけているようだな。

「……ほら、キミも返事!」

はいはいハイショーハイショー」

なんだかこのあたりのやり取り、本当に修学旅行みたいなノリだな。

「じゃあ、今から“穴”を開けるよ。そこを通って別の次元を移動するんだ」

いわゆるワームホール的なやつか。

気取った横文字並べられるのも癪だが、“穴”っていう表現は風情がねえなあ。

「開いたらすぐに入るように。長く開けておくと次元警察煩いから、すぐに閉めないといけない」

そう言ってガイドは、謎のオブジェクトを放り投げた。

放り投げられたオブジェは空中で静止し、1秒と経たない内に“穴”を作り出した。

穴の先に見える景色は淀んでいて見えにくいが、自分たちが今いる世界とは明らかに違うと感じさせる。

「さあ、ボクについてきて! 早く入って!」

未だモジモジしている弟の手を引いて、俺はその空間に勢いよく入った。

(#65-4へ続く)

2018-11-19

増田プログラマー養成講座 その22 データベース設計 概念物理

前回は、DB設計の(1)要件定義を学びました。

今回は、DB設計の(2)概念設計、(3)論理設計、(4)物理設計を見てみましょう。

 

DB設計の流れ

  1. 要件定義
  2. 概念設計
  3. 論理設計
  4. 物理設計

 

DB設計の教材

データベース解説本やWeb記事を調べてみた。

  1. 本「スッキリわかるSQL入門」 第12章 テーブル設計 https://book.impress.co.jp/books/1111101167
  2. Web記事「できるエンジニアになるためのちょい上DB術」 https://www.edifist.co.jp/lecture/dbdesign/

 

スッキリわかるSQL入門」のDB設計説明コンパクトにまとまっていて、分かりやすいと思いました。(是非一度読んでみてください。)

 

 

 

概念設計論理設計物理設計概要

スッキリわかるSQL入門」第12章の説明(p.374)を参考にしてみよう。(詳しくは本を読んでみてください。)

 

概念設計

管理すべき情報はどのようなものなのかを整理します。

データベースシステムに関することは考えず、要件に登場する情報だけをザックリと把握します。

たとえば、家計簿データベースであれば、扱うべき情報として「利用者情報」や「入出金情報」などがあることを明確にします。

また、情報間で関連がある場合、どのような関係があるかも併せて整理します。

 

論理設計

概念設計で明らかになった各情報について、RDBを使う前提で構造を整理し詳しく具体化していきます

論理設計では「どのようなテーブルを作り、それぞれのテーブルにどのような列を作るか」まで明らかにすれば十分です。

型や制約など、付随的な部分については考えません。

 

物理設計

特定DBMS製品(たとえばMySQL)を使う前提に立ち、論理設計で明らかになった各テーブルについて、その内容を詳しく具体化していきます

すべてのテーブルのすべての列について、型、インデックス、制約、デフォルト値など、テーブル作成必要なすべての要素を確定させます

この物理設計に基づいて、CREATE TABLE文などを含む一連のDDL文を作成し、最終的にデータベース内にテーブル作成することができます

 

本書の「図12-4 データベース構築のおおまかな流れ」も参考にして欲しい。

入力 お客様要件(全国の倉庫商品があって、その在庫管理したいんだけど~)

 

 

●処理 DB設計作業

 ・概念設計:(商品)(在庫)(倉庫) …ER図を作成

 ・論理設計:[商品][在庫][倉庫]    …正規化

 ・物理設計:[SHOHIN][ZAIKO][SOUKO]  …使うDB仕様に合わせてテーブル定義表を作成

 

 

●出力 DDL

 ・CREATE TABLE

 ・CREATE VIEW

 ・CREATE INDEX

 

 

 

(2) 概念設計

 

ER図とは?

ER図とは、「Entity-relationship Diagram」(実体関連図)の省略形だ。

 

ER図の用語

コンピューター用語英語ばっかりだから日本語にして欲しいよねw

 

ER図の書き方
  1. エンティティ―」は四角い箱で書く。
  2. 箱の中にエンティティ―の詳細な中身=「アトリビュート」を書く。
  3. 箱と箱を「リレーション」の線でつなぐ。
  4. 線の両端に「カーディナリティー」「オプショナリティー」の記号を書く。

 

ER図で使う記号は、「IE記法」や「IDEF1X記法」など、いろいろな規格がある。

情報処理技術者試験のデータベーススペシャリストの問題では、「UML」という図の記法も使われる。

 

 

 

(3) 論理設計

 

正規化とは?

正規化 Normalization」とは、データの形を「正規形」(Normal form)に変えること。

ざっくり言うと、テーブル(表)を分割して、データの重複や不整合を解消する作業だ。

 

テーブルの形を変えていくステップには、第1~第5まで5段階ある。

  1. 第1正規
  2. 第2正規
  3. 第3正規
  4. 第4正規
  5. 第5正規

それぞれの変形方法について理解しておこう。

実務では第3正規形まで正規化できればとりあえずOK

 

第3.5正規形(ボイス-コッド正規形)

第3正規形をより厳密にした「ボイス-コッド正規形」という形もある。

第3と第4の間なので「第3.5正規形」とも呼ばれている。

(ボイス-コッド形もカウントに入れたら、第1~第5、+第3.5で計6段階になる。)

 

非正規

正規化を進めると、SQLJOIN」の利用が増えてくる。JOINを多用する処理は遅い=DBの性能低下につながる。

第3正規形まで分割しても、実際に使ってみて遅い場合は、第2正規形や第1正規形に戻して使うこともある。これを「非正規化」とか「正規化を崩す」などという。

 

RDBでは処理速度が遅くなる場合、代わりに「NoSQL」を使う場合もある。

 

 

 

(4) 物理設計

 

時間がない場合、先にGUIDB管理ツールでデータベース作成してしまい、その後でテーブル定義表を作成することもある。

 

DB設計に慣れてきたら上記の各段階はすっ飛ばして、いきなりデータベースを作れるようになるだろう。

 

ここまで、SQLの使い方やデータベース設計について学びました。

次回は、その他のSQLに関連する話も見てみよう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181026145516 増田プログラマー養成講座 その12 データベース参考書

anond:20181028152656 増田プログラマー養成講座 その13 SQL文法

anond:20181031014212 増田プログラマー養成講座 その14 Webアプリの試作品作成

anond:20181101225335 増田プログラマー養成講座 その15 Webアプリの完成見本

anond:20181101230220 増田プログラマー養成講座 その16 Webアプリの完成見本(続き)

anond:20181104161900 増田プログラマー養成講座 その17 Webアプリの骨組み

anond:20181104233013 増田プログラマー養成講座 その18 SQLデータの追加と取得

anond:20181110120715 増田プログラマー養成講座 その19 SQLデータ更新

anond:20181110182445 増田プログラマー養成講座 その20 SQLデータの削除

anond:20181111205255 増田プログラマー養成講座 その21 データベース設計 (1)要件定義

anond:20181119224031 増田プログラマー養成講座 その22 データベース設計 概念物理 ←★今ここ★

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

[] #65-2「短くて長い一日」

「一緒に別の次元に行ってみよう! そうすればキミも、ボクの言っていることを信じるはずだ」

『別の次元

その言葉が俺の琴線に触れた。

「別の次元ってのはアレか。パラレルワールド、平行世界的なヤツか?」

わず興味本位質問を、食い気味にしてしまう。

今までにない俺の好反応に、ガイドもたじろいでいた。

「んー……まあ広義的には」

「そうか……やっと分かってきたようだな。そういうのでいいんだよ」

「どういうの?」

俺が知っている限り、こいつが今までやってきたことは尽く期待外れだった。

人の家の庭を焼き払う謎のオブジェクト

生身の俺に妨害されただけで、何もできなくなる程度の機能しかないダサいスーツ

色々なものを無理やり詰め込んで何がやりたいかからない、使い勝手の悪そうな多機能端末。

その他、俺の弟相手にも色々と披露していた。

将来生まれてくる子供人生シミュレーションできる装置だの、罪と罰を測ることができるメーターだの。

こいつにとっては未来科学力を証明しているつもりなのだろうが、いずれも胡散臭い感性がズレている。

もっと普遍的イメージに応えるようなものなら良いのに、どれも頭でっかちだったかコメントに困っていた。

シンプルに空を自由に飛べるだとか、玩具兵隊だとか、世界旅行に行けるようなものとかでいいのに。

いつもヒネたことばかりやってくるから、凄いかどうかイマイチからないし、興味も湧いてこない。

だが今回、やっとマトモなものが出てきてくれたようだ。

「じゃあ、その別次元について、話を聞こうか」

これでもジャリガキの頃はSFに慣れ親しんでいた。

今でこそ落ち着いてはいるが、ここにきてその頃の気持ちが再燃していく。


…………

そして出発当日、早朝。

待ち合わせ場所であるガイド居候先に来ていた。

次元に与える影響を最小限にするため、身に着けるものや、持ち物は最低限だ。

しみったれた小旅行である

それでも俺がOKしたのは、もちろんパラレルワールドというものに惹かれたのもあるが、“とある条件”を飲んでもらったからだ。

「後は弟くんが来るのを待つだけだね」

俺は同行者、つまり弟も共に連れて行くことを条件にした。

さすがに苦手な相手と二人っきりなんてのはツラすぎるからだ。

見知った身内でもいれば、多少はマシになるだろう。

……だが、弟が来るのが遅い。

から来ると言っていたが、まさか二度寝しているんじゃないだろうな。

あいつは俺以上に朝に弱いから、有り得そうで不安だ。

「うーん、弟くん来ないね。そろそろ出発なんだけど……」

次元を飛ぶんなら、今の時間とか気にしなくてもいいだろ」

「色々とこっちにも事情があるんだよ。好き勝手次元を跨ぐと厳罰になるからあんまり融通利かすわけにはいかないんだ」

「じゃあ、このままだとお前と二人で旅行ってか?」

「まあ、元から二人で行く予定だったんだし同じことでしょ」

勘弁してくれ。

こいつと長時間一緒とか、補正をかけてもロクな思い出にならないぞ。

(#65-3へ続く)
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん