No.51
>>47
>>49
はたぶん会社で上司に怒られてサビ残させられてストレス溜め込んでるんだろう。
>>1
よ許してやれ。
>>47
>>49
はたぶん会社で上司に怒られてサビ残させられてストレス溜め込んでるんだろう。
>>1
よ許してやれ。
ハロワの職業訓練でデータベースやってるんですが。
レス数: 130
概要: >>46 >>47 >>49 はたぶん会社で上司に怒られてサビ残させられてストレス溜め込んでるんだろう。 >>1 よ許してやれ。
>>47
>>49
はたぶん会社で上司に怒られてサビ残させられてストレス溜め込んでるんだろう。
>>1
よ許してやれ。
No.52
受注した後何もしなかったの？
No.53
No.54
考えてみれば貸出日と返却日だけあればいいのか。
あ、これ
>>30
の話ね。
No.55
は
飛び級で大学卒業したけど大人になるにつれて普通の人と変わらなくなっちゃって
挫折して仕事辞めて引き籠もっている一人じゃ何もできない元天才少女
って設定でOK？
No.56
返却日はクエリで出せば良いだろうし。あんまりごちゃごちゃ余計な機能つけるとおわらなそうだな。
No.57
の設定で誰か
>>1
のキャラ絵描いてくれよ
No.58
ごめん、忙しくてテキスト読み返す時間があんまりない。
思い出せる範囲で答えるけど。
受注した相手の情報とかもあったような気がする。
No.59
No.60
＿
／,.ｧ､＼
( ﾉo o ) ） 空
)ヽ ◎/(. 気
（／.(･)(･)＼ . 嫁
（／| x |＼）
／／＼＼
. （／ ＼）
No.61
ビデオテーブルと一緒にするかな？
No.62
マスターは会員テーブルとビデオテーブルの2つだと思うよ。
貸し出しテーブルは入出の記録を保存するためのテーブル。呼び方は知らないが。
というのか30である俺が想定したテーブル構造。
No.63
ほんとうに酷い授業内容だったんだなと同情するけど、
貸 し 出 し テ ー ブ ル は 必 須 だ
No.64
貸し出しテーブルはビデオテーブルと一緒にしても問題ないかな？
っていうかするとヤバイのか？
同じビデオでも貸し出し記録は別にするほうが良いかもしれないけど、
データの入力時にめんどくさそう・・・
No.65
授業はホント酷い。MOS試験に合格する程度の内容で、
データベースそのものの構築やら何やらはあんまり教えてくれない。
そのくせ、EXCELに時間かけたりいきなり仕様書を書けとか
よくわからないカリキュラムだった。
さて、飯でも食うか。
No.66
そういう実用性皆無の手抜き仕様なら会員マスタいらないじゃん。
つか、ビデオテーブルだけなら会員マスタとリレーションしようがないし。
No.67
酷い
>>1
の脳みそに酷いカリキュラムじゃもうどうしようもないわな
No.68
好きにしなさい。以上。
No.69
No.70
見知らぬ初心者らしき人に向かってネットストーカーですか？キモチワルイ奴だな。
No.71
ここら辺の理屈について詳しく
No.72
とりあえず、君が考えた「ビデオテーブル」の項目上げてみ。
そのほうが突っ込み入れやすいし、どうして駄目がわかるだろうから。
No.73
No.74
エヴァのアスカ。
そんな設定のSSがあったような気がする。
No.75
No.76
No.77
よほど現実社会で虐げられてるんだろうけど。
No.78
あの初期画面見てると萎えるのは漏れだけ？
No.79
会員テーブルと、ビデオ（商品）テーブル以外に貸し出しテーブルが必要だという話があったけど。
それをやると、貸し出し記録が複数出てくるのでフォームやレポートを作る際に、
ややこしくなりそうだ。
貸し出しテーブルとビデオテーブルを一緒にして、貸し出し記録は最新のものひとつだけ表示すようにするわけには行かないだろうか？
日数が限られてるので面倒になるテーブル構築はやめたいんだけど。
貸し出しテーブルを作ると面倒なことになりそうなんで辞めようか考えてるんだけど。
No.80
No.81
評価は気にしてない。所詮ハロワの訓練だから・・・
期限内に簡単に出来ればそれでいいと思ってる。
No.82
レンタルビデオ屋のデータベースだと「こんなんじゃ使い物にならないよｗ」
とか余計なこと言われそう。
No.83
そのために返却日があるんじゃないの。
どの道、一人が一本しか借りないとは限らないし、
貸し出しテーブルを会員番号と返却日が入っていない
データで抽出すればいいだけじゃん。
>返却日はクエリで
とか言っていたけど、どんなクエリか知らないが
それは返却予定日じゃないの?
No.84
第三正規化しない方が後々面倒になるぞ
No.85
貸し出しをテーブルにする必要があるかもしれないが、なんかめんどくさそう。
貸し出しテーブルはひとつの商品につきひとつの日にちだけにして、
貸し出し中かそうでないかわかるだけにするという手はないだろうか？
No.86
今まで楽をしようとして逆に大変だった経験ないか？
No.87
No.88
作ってると良いぞ。
フォーマットはどうでもいいから。
漏れは面接の際、それを提出したところ、PGじゃなくて
SEとして就職できたぞ。
No.89
全く身に付いていないならただの時間の無駄ジャマイカ！
No.90
話は脱線するけど。
SEって仕事が大変じゃないですか？
俺ハロワで受けてる職業訓練だけど適性がないような気がするので
卒業後は別の仕事をしてるかもしれない。
No.91
だったら課題なんてやめて遊びに行こうぜ
No.92
楽しむことが重要だと思うが。
どの道、ハロワの職業訓練なんて現場では
全く役にたたなかったし、（漏れは職業訓練校卒業生）
先輩に教えてもらったり、
自分で四苦八苦したことでなんとかかんとか
業界で食べていけるんじゃないかな？
今やろうとしているDBについても
「こんなテーブルが必要じゃないか？」
「こんなフィールドがいる」とかいろいろやってみること
だと思うよ。
やってできないことはない！
No.93
そうですな・・・・
No.94
>>1
。応援してるぞ！
No.95
ありがとう、あれからレンタルビデオのデータベースを作ることに成功しました。
No.96
とかにすれば良かったのにｗｗ
おれはゲームやらないからいらないけど、
へんに業務っぽくて、しかも使い物にならないものよりも、重宝がられそう。
No.97
顧客番号（主キー）
住所
氏名
ビデオマスタ
ビデオ番号（主キー）
貸出区分（主キー）
タイトル
※貸出区分は、新作、旧作などの区分
貸出区分マスタ
貸出区分（主キー）
金額
※貸出区分によって、金額が決まる。一泊なら１００円とか。
貸出履歴
顧客番号（主キー）
ビデオ番号（主キー）
貸出日
返却日
こんなもんかな。私は正規化とかよくわからないので
おかしな所があったら、教えてほしー。
No.98
ビデオとDVDが混在しているし、ビデオも一本とは限らないし、致命的なのは
この貸出履歴の構成だと二度と同じビデオを借りられない・・・。
結構、むずかしいのね〜。
No.99
UMLとか項目定義するツールを使って、レビューを繰り返して、正規化するの？
繰り替えし項目をなくしたのが、第二正規形、関数従属なくしたのが
第三正規形とか教科書どおりのことは知ってるつもりだけど、どうも
うまく実作業に結び付けられない。実際の設計って、第一正規化→第二正規化
→第三正規化というふうにちゃんと段階踏んでいくものなの？
No.100
