モデル作成に関する質問、質問に対する回答、
作ったモデルの自慢、自慢されたモデルの批評など、
モデリングに関すること全般を扱います。
ソフトの使い方に関する話題、物理的なモデルの話題はご遠慮ください。
EX.
このソフトで○○の機能は〜 → ソフトウェア板へ
○○の組み立てが完成して、これから塗装〜 → 模型・プラモ板へ
モデリングツール
○SVG Cats
製品情報
ttp://http://www.sage-p.com/svgcats.files/svgcats.htm DL
ttp://http://www.vector.co.jp/soft/dl/win95/art/se251284.html SVG(ベクター画像をテキストで記述するデータフォーマット。要はXMLの一種)でモデル図を描画するツール
●ER/Studio
製品情報
ttp://http://www.jsys-products.com/product/erstudio/ トライアル版DL
ttp://http://www.jsys-products.com/download/trial/erstudio/ ●AllFusion ERwin Data Modeler
製品情報
ttp://http://www.caj.co.jp/allfusion/erwin/data_modeler.htm トライアル版DL
ttp://http://www.caj.co.jp/registration/allfusion/erwin_pm.htm ●Rational Rose
製品情報
ttp://http://www.rational.co.jp/products/rose/ 評価版請求
ttp://http://ops.rational.co.jp/CatalogHassou/f_req.html ●Microsoft Visio Professional
製品情報
ttp://http://www.microsoft.com/japan/Office/visio/evaluation/ 評価版配布請求
ttp://http://www.microsoft.com/japan/office/visio/evaluation/trial/ SVGビューア
○SVG Viewerプラグイン
ttp://http://www.adobe.co.jp/svg/ ダウンロードページ SVG画像を閲覧するためのプラグイン
ttp://http://book-i.net/ad07/ 南下不安。
きわものに飛びつくよりIDEF1Xで我慢しとけといいたい
そだよ？知らなかった？
その手の比較には必ずっていうほど出てくる。
ｵﾏｴの場合は、ただのｵｴｶｷﾂｰﾙと一緒だろうが。
いろんなツールが対応してるし、ERDと違って描き手によって表現が少しずつ違うってこともない。
ERDは、ツールによって表現が違うから、統一できなくて気持ち悪い。
つーかIDEF0の描き方がよくわからん・・・だれかいいサイトなり書籍なり教えて・・・
独学じゃ限界もあるだろうし。
なんかいい練習法ないかな？
ミリオンゴッドで稼ぎたい人はいませんか？
攻略法でも体感機でもありません。一日十万はいけます！
(私自身も三人グループで八十万いきました★)
詳しい内容については確実に連絡の取れるメールアドレスで
god-game@jp-q.ne.jpまでお願いします。
量産タイプのコピー品と違い、数に限りがありますので稼ぎ
たい人はお早めにどうぞ！！！
データモデリング基礎講座―データベース設計を楽しもう! DB Magazine SELECTION
ttp://http://www.amazon.co.jp/exec/obidos/ASIN/4798101109/qid%3D1057755191/249-8156321-9557966 実践的データモデリング入門 DB magazine selection
ttp://http://www.amazon.co.jp/exec/obidos/ASIN/4798103853/qid%3D1057755316/249-8156321-9557966 業務別データベース設計のためのデータモデリング入門
ttp://http://www.amazon.co.jp/exec/obidos/ASIN/4534032501/ref=pd_sim_b_dp_1_4/249-8156321-9557966 ちなみに今手元にないし、全部カバーかけて表紙覚えてないので、
感想はすぐかけません。であ。
データモデリング基礎講座 はすごくわかりやすかった。
でもあれに出てくる書き方であるシュレイアーメラー？（T字型というやつなのか？）
ってはやってんでしょうか？
手元のVisioじゃあの書き方はできないし
T字形いいよ。漏れは7年ほどやってる。設計品質の確保には便利。
でも書籍だけだと細かいところで悩むので、お金があるならセミナーを
受けるといいかも。漏れは受けたことはないし、自己流でアレンジしてる。
ちなみにツールはErwinでIDEF1Xでやってる。考え方がT字形ってことで。
多分佐藤氏からすれば邪道なのだろうが、納期に間に合い品質と性能が
出れば、それで良いのだよ（ｗ
対話形式の内容なので、イメージがしやすい。
モデリングの入門者にはいい本だと思う。
ttp://http://www.amazon.co.jp/exec/obidos/ASIN/4797321296/qid=1057970961/sr=1-1/ref=sr_1_2_1/249-9336605-0510750 visioって6万くらいでしょ？
ほかのは？
ageるな！
ヴォケッ！！
ドラゴンボール厨が寄ってくるだろ！
体中に広がるパノラマー
の流れに思わず笑ってしまった。
尊敬される
ﾌﾟﾁﾜﾛﾀ
ttp://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/vsent7/html/dvcondatadesign.asp ttp://http://cgi32.plala.or.jp/mg916/dragon/ ２ちゃんねるｐ
ttp://http://www11.plala.or.jp/mg916/ こっちにも来てください！！
また、練習方法とかあったら教えてください。
はじめたほうがいいよ。
あとDBと書くと今の時期 ドラゴンボール設計って感じに
見られてしまう。。。（わけないか）
ずばりAccess。会社でOracleのCDがゲットできるなら家のPCにインストル
してそれで遊ぶことも出来ます。この場合もAccessと併用して取り扱うと
能率が向上します
（SQL PLUSかナニかでクエリーを投げる→出てきた結果とAccessで覗き見ている
テーブルのデータを比較等）
会社にOracleなどのソフト類がない場合，自宅で練習にはとりあえずAccessでしょう。
自分で買ってもそれなりに安い
（そうしなくても大概は会社にCDあるからそれを自宅のPCに 以下自粛）
のとヘルプがしっかりしているから。
Access‐Oracle間はクエリーの命令式等多少の違いはありますが
基本的な取り扱い方はほぼ同じです。
データベース設計の一番の肝は データをどう整理していくか なので
（俺の意見ですがどうなんですかね）表領域の取り方とかそういう
カコイイことは色々習熟してから手をつけたほうがいいでしょう。
DB2 でも勉強できるよ。
公的資格もオラオラと同様にあるし。
Oracleは、勉強しようとおもって一時OTN Pro入ってたから、
開発用ライセンスを持ってます。
勉強したいのは、DBに依存しない部分についてです。
このスレタイにあるような、モデリングなんかを覚えたいのですが・・・
Accessも、Office2000 Proがあるので、触れる環境ではあるし、
ちょっとしたものなら作れます。
正規化なんかもちょっとはかじりました。
しかし、その前の段階をどうやって勉強すればいいのかわからないんです。
DFDなんかも覚えてみたはいいものの、どこでどう使えばいいのかもよくわからないし・・・
DB2は、見たことすらないです・・・
ﾋﾟｭ.ｰ （ ・３・） ( ＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
＝〔~∪￣￣￣∪￣￣〕
＝ ◎――――――◎ 山崎渉&ぼるじょあ
WEB+DB Pressの11号「RDBMS再入門」中々参考になった。
お勧め。
へ〜・・・ってｫｨ！完売じゃねぇかYO！
ttp://www.gihyo.co.jp/magazines/wdpress/archive/Vol11 まじで。
数日前に近くの書店で見かけて買ったんだけど。
渋谷のBook1にもあったと思う。
T字型？このスレで紹介されてた書籍に載ってたような・・・？
今手元にないんで、あとでISBNとか晒す。
ttp://http://www.amazon.co.jp/exec/obidos/ASIN/4798101109/qid%3D1057755191/250-1323438-1825824 これですよね。
これは持ってるんです。
他に分かりやすい本ありますか？
やっぱりコースを受講するしかないのかな。
「論理データベース論考―データ設計の方法:数学の基礎とT字形ER手法」
ttp://http://www.amazon.co.jp/exec/obidos/ASIN/4883731340/qid=1060778023/sr=1-1/ref=sr_1_2_1/250-1323438-1825824 この本は難しくて・・・
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
ttp://http://www.sdi-rad.com/index2.html １）モデルをカテゴリー化するときってどんなときですか？
パートと従業員の例だと解りやすいのですが、逆にこれだと区分つけた方が
理解しやすくないですか？
２）１：NのリレーションでNが依存エンティティの時、Nの外部キーって必ず主キーにしなくては駄目？
教えて君で申し訳ないですけど、よろしくお願いします。
２）依存だと主キーになっちゃうだろうな。漏れはいつも非依存で設計してる。
どっちも漏れ流なので、IDEF1Xの正道としてどうかというのはわからん。
ttp://http://www.modelcreator.com/ ってどうでつか？
$150 程度と手頃そうなんでつが。
埋め込んでしまう。
ttp://http://www.molips.com/jp/ どういう風に単品在庫＆売上管理してのでしょうか？
単純に店員が人力でディスカウントという名の売上レコードを挿入するだけだと
ミスは多そうだし、粗利率や回転率なんかも後々で必要になるとややこしい話になりそうなので
以下のようなこと考えてるのですが、王道みたいなのがあれば教えて下さい。
＊売上明細テーブル＊
品番 名 基本単価 値引 値引後単価 個数 金額 値引コード
1 靴下A 500円 157円 343円 x 2ヶ = 686円 A
2 靴下B 500円 157円 343円 x 2ヶ = 686円 A
3 靴下C 500円 157円 343円 x 3ヶ = 1029円 A
4 靴下D 500円 157円 343円 x 4ヶ = 1372円 A
5 靴下E 500円 157円 343円 x 5ヶ = 1715円 A
6 傘A 1000円 0円 1000円 x 2ヶ = 2000円 NULL
---------------------------------
合計 7488円
＊値引の157円は値引テーブルを検索する
＊値引テーブルの内容＊
値引コード 個数 値引合計金額 値引単価
A 1ヶ 0円 0円
A 2ヶ 0円 0円
A 3ヶ 500円 166円
A 4ヶ 500円 125円
省略
A 16ヶ 2500円 157円
売上明細.金額など正規化でわざわざテーブルに値を保存しなくてもいいものも
説明の為含めています、あしからず。
わからんけど、それはデータベースのやることじゃなくて、
売上げ管理ソフトのプログラムがやることではなかろうか。
そうです。実際の値引き額のSETは
売上げ管理ソフトのプログラムからUPDATE系のストアドなどを叩こうと思うのですが
データモデリングで王道のサンプルみたいながあれば知りたかったのです。
あとマクドナルドのバリューセットなんかはどうなってるのだろう？
とかはデータモデリングの範疇じゃありませんか？
とりあえず、上記に載ってる本のどれか買って色々なSample見てみます。
なんかセット用のフィールドを作った気がする。
詳しいことは忘れた。
クラス図とは、全く違ったものになると思うのですが、
UMLとER図の連携?というのは、どうなのでしょうか？
まったく別物として考えるのでしょうか？
たまに、本で、クラス図を利用して、データベースを、表現したりしているものもあるのですが、
どのような、使い分けをするものなのでしょうか？
ER 図も書ける EA 使うってのは？
ttp://http://www.sparxsystems.jp/ あと、買ったっきり読んでないのでわからんが（をひ）
「データベース設計のための UML」参考になるかもね
ttp://http://www.amazon.co.jp/exec/obidos/ASIN/4798103675/ 以下の２つはよさげなんだけど、日本語のハンドリングにちょっと難点があり。
■DDS-Lite
ttp://http://www.chillisource.com/ ttp://http://www.dds-lite.com/ 現在正式リリースされているのはライト版のみ。フルセットの Pro バージョンは
開発中。現在、ダウンロード版が特売価格で $79.95
ライトバージョンでも、DFDを扱える。（でもリーバースエンジニアリング機能はない）
ER図の日本語表示はなんとかなるが、ダイアログはだめ。
リソースはいろんなところに分散していて直すのが面倒。
また、無理矢理２バイトコードをぶちこむと落ちることがある。（うーむ）
■CaseStudio2
ttp://http://www.casestudio.com/ フルセット版で $329 ER、DFD （ライト版は DFD 非対応）
ER 図そのものに日本語の表示は可能なものの、ダイアログボックスが全滅
リソースいじろうとしたが、変な実装で、フォント名かえると、起動できない。
だけで、日本語のハンドリング問題なかったよ。安いんで、とりあえずレジスト。
使い物になるかな？
三足セットを別商品にして\1,000の単価をつけ、
三足セットの内訳「靴下×3」を部品表構造で表現するのは？
在庫と商品を別テーブルにすればいいんじゃないかな？
データの発生源から entity を抽出してゆく方法は、
目からうろこでした。
正規化違反せずに実装する例が示されていません。継承属性を含むモデルを正規化違反せずに実装する
例を示せる人いますか？（もちろん著者は示せるだろうが）教えてください。例えば、p153 図5●将来の日別在庫推移
を管理する、における（商品C）は継承属性を含むモデルとして挙げられます。
トリガーとか使って関連テーブルから
読み込ませるとか？
いいホームページとかないですかねえ？
ITアットマークとか見てるのですが
モデリングに関してはなかなかないですね。
これ、リバースエンジニアリングしたのをさわった後、
実際にテーブル構造を書き換えるにはどうすればいいのでしょうか？
会社で社員が部門に所属しているのを表すとき、
社員（社員コード、氏名） 部門（部門コード、部門名） 所属（社員コード、所属部門コード）
のようになるようなんですが、T字型でないERの場合は
社員（社員コード、氏名、所属部門コード） 部門（部門コード、部門名）
となると思うのです。
T字型ERでは所属というのを設ける理由はなにでしょうか？
社員が一人が複数の部署に配属される場合以外は
あまり必要がないような気がしますね。
社員と部門の間に依存関係が存在するかどうかの違い。
部門に所属しない社員が許容されるならば、必然的に上の形になる。
所属部門コードにNULLを許して下の形の社員テーブルとする場合は、
概念スキーマ上の社員と所属を結合したものと考える。
あとはの言う通り、所属の主キーを何にするかによっても
表現するものが変わる。
データの状況や考え方次第ということですね。
うーん、納得できないなあ。
部門に所属しない社員がいるとしても、社員が最大ひとつの部門にしか
所属できないとしたら、概念レベルでも「所属」は必然的ではないと思うな。
概念レベルでそういうエンティティを設けてそのまま実装したら、
ひとりの社員が複数の部門に所属しないための余計なコードを書かなきゃ
いけなくなるからね。
>概念レベルでそういうエンティティを設けてそのまま実装したら、
>ひとりの社員が複数の部門に所属しないための余計なコードを書かなきゃ
>いけなくなるからね。
なんで？制約で表現できると思うのだが。
「所属」にどんな制約を組み込めば、
複数の部門に所属する社員が登録されるのを
避けれるんだろう。
社員キーをユニークにするんじゃだめなんか？
社員コード＋所属部門コード
になるんではないのかな。
もしユニークキーが社員コードだけだと
すると、「所属」ってのは「社員」とキー
がいっしょってことになるな。
所属部門コードがＮＵＬＬではありえないなら
「所属」って意味ないような気がするんだが。
>もしユニークキーが社員コードだけだと
>すると、「所属」ってのは「社員」とキー
>がいっしょってことになるな。
>所属部門コードがＮＵＬＬではありえないなら
>「所属」って意味ないような気がするんだが。
「社員」「部門」はエンティティ、「所属」は「社員」と「部門」間の
リレーションシップを表現している。
意味がないと思うなら、の言う通り、論理設計の段階で
結合してしまえば良い。
そのモデルだと所属が変わったときにその事実がどこにも残らないだろ。
モデリング対象の会社に社員の所属変更があるのなら、
配属イベント（配属コード、社員コード、部門コード、配属日）を置く。
そこから所属（＝指定日付における所属状態）がすべて再現できる。
そりゃ要件しだいだな。
履歴が必要ならそういう設計もするだろうが、必要ないなら
徒にトランザクション性能を下げるだけだし。
結局のところ、業務分析した結果にそれが現れるかどうかだろう。
（健康体） （喘息）
1.（神が喘息であるかないかを決める）
2.K 喘息でない人 A 喘息の人は
は体力がある 体力がなくなる
3.K A 行動力、
五感（嗅覚）が鈍り感性が変化する
4.K&A 神は異常な感性の人間は本来人に迷惑をかけ
るから外に出てはいけないと思っている。
5.K 変化なし A アトピーになる
6.K 正常な感性 A 外に出なくなりさらに異常な感性になる
7.K 正常な人間 A 異常な人間（レッテル）
「業務分析」の結果に配属履歴が現れるかどうかは、「業務」によって決まる。
だから「モデリング対象の会社に社員の所属変更があるのなら」と言ってる。
業務は個別アプリケーションの都合で変わりはしないからな。
分析結果に履歴形式が現れた場合に、実際に履歴テーブルとして実装するかどうかは
設計段階で決めることで、トランザクション性能云々はこのときに考えること。
はそういうことを踏まえずに、
配属イベントをすっとばして所属の話だけをしてるから、
それはおかしいっつってんの。
>「業務分析」の結果に配属履歴が現れるかどうかは、「業務」によって決まる。
これは問題ないが、
>だから「モデリング対象の会社に社員の所属変更があるのなら」と言ってる。
ここがおかしい。所属変更があるということとその履歴が必要というのは
要件としてイコールじゃないから。
だからが最初に言っている
>そのモデルだと所属が変わったときにその事実がどこにも残らないだろ。
これが必要かどうか次第なわけ。
実際、一人の社員が複数の部署に所属し得るという事実を表現するのには
のモデルで十分だし、それは所属変更がありうるとしても変わらない。
>のモデルで十分だし、それは所属変更がありうるとしても変わらない。
うーん、やっぱり設計と業務分析の区別がついてないね？
のは、テーブル設計（設計の成果物）としては有りだが、
モデル（業務分析の成果物）としてはおかしいんだよ。
ここはモデリングのスレだろ。
>のは、テーブル設計（設計の成果物）としては有りだが、
>モデル（業務分析の成果物）としてはおかしいんだよ。
おーい、が業務分析だと言っている香具師がどっかにいたか？
もしかして「モデリング」＝「業務分析」とか？
つか、にとっては「業務分析」と「テーブル設計」の間って
ないのかよ？
>ここはモデリングのスレだろ。
そう。データモデリングのな。
T字ERを自身が持ち出しているんだから、分析の文脈で捉えるのが自然だろ。
>もしかして「モデリング」＝「業務分析」とか？
>
>つか、にとっては「業務分析」と「テーブル設計」の間って
>ないのかよ？
？？？ なんでこう話がかみ合わないかな…。
もしかしてはT字ERを知らないんじゃない？
T字型ERは業務分析だけで使うもんじゃないだろうに。
まぁそれは言葉の問題だとしても、分析フェーズのoutputってのは
要求分析を経てシステム境界等が明確に定義されているべきもの
なんで、要件と無関係にのような断言はできるはずがない。
純粋に業務分析の話ならば、社員の所属変更というごく一般的な
プロセスについてなんらかの言及ができてもおかしくはないと思うが、
誰も最初からがそういう意味での業務分析のことだと思って
いないし、自身そのつもりじゃないだろう。
もともと業務分析じゃないものを「業務分析としておかしい」と言われ
ても意味不明だし。
とりあえずの
>のは、テーブル設計（設計の成果物）としては有りだが、
>モデル（業務分析の成果物）としてはおかしいんだよ。
これだけじゃ何も言っていないのと同じだから、具体的にどう
おかしいのか説明してくれないかい？
確かに俺はT字型ERは使ったことがないしよく知らないけど、
業務分析から設計までスムーズに落とし込めるという謳い文句の
T字型ERで、逆にそこのところの明確な切り分けをどのように
行うのか興味があるしな。
>誰も最初からがそういう意味での業務分析のことだと思って
>いないし、自身そのつもりじゃないだろう。
そうか、自身が業務分析のつもりが全くないということが、
まだサワリの段階だったら十分ありえるわけだね。了解。
具体的にどうおかしいのかの説明かあ。
困ったな、俺にとっては自明なことなんだよ。T字型ERを算数にたとえると、
「算数では1+1=10になるようなのですが、なぜ10になるのですか？」
という質問のどこが具体的にどうおかしいのか、と聞かれてるような感覚。
でも「1+1は算数では2が答えだから、10になるという仮定は違うよ」という
言い方は算数を知らない人には絶対うまく伝わらないよね？
なので、どう説明したらいいものかと。
うまくできるかわからんが、T字型ERの体系をざっくり解説してみようか？
別に、T字型ERマンセー、って主張するわけでもしたいわけでもないけれど、
変な誤解（のいう「所属」がT字型ERで普通に導かれる、というような）は
解きたいとは思うんだ。
の「配属イベント」が必要という話じゃなくて、の「所属」が
余計だという話をしてたわけね。
>なので、どう説明したらいいものかと。
要は「T字型ER」での「業務分析の成果物」にはなんらかの「禁則」が
あって、はそれに反している、ということだろう？それを一言で
指摘してもらえば済む話かと思ったんだが。
というか、具体的に、ってのは
>変な誤解（のいう「所属」がT字型ERで普通に導かれる、というような）は
>解きたいとは思うんだ。
というようなことををはっきり書いてもらえばそれでよかったんだが。
>あって、はそれに反している、ということだろう？
そういうこと。回りくどくてすまん。
実装については何ら言及していないと理解してる。
Ｔ字型でモデリングした後、実装で
社員コード・名前・部門コード
部門コード・部門名
なんて実装もありだと思われ
−−−−−−−−−−−−−−−−−−−−−−
Ｔ字型マンセーの解説キボン
もう一回ちゃんと本を読め
論理モデルと物理モデルの乖離を否定するのがT字形だぞ
それは幻想と思ってる。もう３回読んだよ（ｒｙ
プライマリーキーがどれになるかがわからないリソースや
イベントの例に悩んでいてこう結論つけた。このまま実装す
るなら全テーブルに連番でも振らないと実装出来ない予感。
ＤＷＨ（データマート）やチューニングの話がミスディレクション
になってるんだよきっと。佐藤さんは推理小説好きなんだろう
「論理データベース論考」のＰ１９８にこうある
・対照表を実装するのかしないのか、という点を判断する
・サブセットについては、最上位のセットと・・するのかを判断
・ＶＥについては、派生源のentityに戻して実装するのか・・判断
結局、実装では属人性を排除出来ていないじゃん（ｗ
まあそれでＴ字形の偉大さが毀損されると思わないけど、
本だけでチャレンジした人はきっとＳＤＩにコンサルを依頼
するしかないのかも。毎度あり〜
ビジネスに出てこないアイデンティファイアを導入したらアウトでしょ。
どういうので悩んでいたのか言ってみて？
俺は論理データベース論考は何十回か通読したけど、
SDIやヒューネットのコンサルもセミナーも受けてない。
考え方を身に付けるのが目的だから、
特定のツールを売り込まれたりしたら嫌だし。
確かに、実装の属人性排除はT字形ERの謳い文句には入ってないね。
DBMS側の技術導入で実装には新しい解が出てくるから、普遍化できない。
（例えば今ならサブセットはORDBMSのテーブル継承で実装できるとか。）
だから、実装にあまり突っ込まないT字ER手法の態度は真っ当だと思うが、
実装まで全部を体系化して欲しいと思う人には物足りないかもね。
この人は何を言っているのだ？
実用書でなく単なる学者のたわごとだと言ってるのかな？
何十回も通読しないとわからないのは実用書ではないからね。
神か仏だな。
まぁ、神や仏は他人を馬鹿にしたりはしないが。
俺は知ってるけど、お前ら馬鹿だなという書き込みほど役に立たないものは無い。
> まぁ、神や仏は他人を馬鹿にしたりはしないが。
神や仏でもないし他人を馬鹿にした覚えはないが。
今日佐藤さんに聞くと、Ｔ字形を大幅に変更したらしいよ。
今年には新書を出すと言われてたので楽しみ。実装につい
ても言及して欲しいといっておいたけど、どうなる事やら。
また数十回読むのでしょうか。大変ですね。
> Ｔ字型でモデリングした後、実装で
> 社員コード・名前・部門コード
> 部門コード・部門名
> なんて実装もありだと思われ
ちょっとマジレスすると、サブセットを上位テーブルに実装
するのは「アリ」だが、対照表を上位に実装するのはルール
違反だと思われます。
Ｔ字形って、プライマリーキーを意識せず実装するっての
が信条のように思ってます。ＤＢによって違うでしょうが、
連番を振ってプライマリーにするのも「アリ」でしょう（多分）。
> 今日佐藤さんに聞くと、Ｔ字形を大幅に変更したらしいよ。
> 今年には新書を出すと言われてたので楽しみ。実装につい
> ても言及して欲しいといっておいたけど、どうなる事やら。
へぇ〜。新書が楽しみだ。期待したいな。
