まだ何も書いてないけど、ロゴから文章まで自分でやってみました！全部フリーってのが良いですね！
新しく使ったツールはこちら。フリーでこんだけできるのは素晴らしい！
スペルチェッカー
Logo メーカー
イメージメーカー
タイトルにはこんなんことかいたけど、MCSAのテスト終わってから、C#の勉強してました。
せっかくマイクロソフト認定資格をとったんだから、マイクロソフト関係のプログラム言語のひとつやふたつ勉強せねばと思いました。
将来的には、SQLのデータと組み合わせたアプリケーションを作ってみたいけど、SQLサーバ、使えるのがないからなぁ。やっぱAzureかな。
で、C#の勉強を始めてから自分の勉強用にYoutubeをシリーズで作ってみました。年取ると忘れやすいもので。ははは。
就職活動を見越して全て英語でやってみました。。。
こんなにひどい英語をしゃべってたなんて、今まで知らなかった。。。
なんか、ねとねとした納豆のようなしゃべり方や。今までごめんな、アメリカ人。
自分の声や発音、くせなんか全部含めて見直すのに、ほんとによい機会だと思いました。
いえぇーい、終わったぜ！
本日無事７０－７６2受かりました。これで晴れてMCSAです。
全部で48問、1000ポイント中、839ポイントで合格です。
700ポイントが合格ライン。パーセントではありません。
ワンスアゲン、なんとも言えない数字ですな。
【合否】終了次第スクリーンに表示されます。
【プレップテストとの違い】約3問だけ違いました。プレップテストは基礎を固めてからのほうが良いですね。古くなってしまうと、必ず初めての問題が出てきますから。
【問題数】48問
【時間】150分でしたが、40分余りました。
【準備期間】約1か月
【ねこの勉強前のレベル】二か月前に70-761に合格していました。AS/400・DB2でストアードプロシージャが読めて変更できる程度。Full Join, Cross Apply, Outer Apply, Intersect, Except などは使ったこともありませんでした。T-SQLは書いたことがありません。Indexは設定したことがありませんでした。Cross Joinは聞いたこともありませんでした。
【試験の傾向】プレップテストがなかったら、何ともならないレベルです。とにかくマニアックな問題がいっぱいでした。とくにVIEWとUser DefindedFunctionの問題とトリガーのごちゃ混ぜになった問題が結構でました。
【注意点】最後の5問はケーススタディで、完全に終了したと思った後だったんで、びっくりしました。それから、思いのほかプレップテストに間違った答えが多くて、正しい答えを探すのがとてもてこずりました。きっと間違えたものを覚えてる可能性もあります。それほど冗長した問題ばかりで、第二外国語のねこにはとっても難しかったです。
【感想】うれしかったけど、実際に覚えたものがしっかりと使えるかというととっても疑問です。。。なんだか悲しいなぁ。こんなに勉強したのになぁ。
さぁ、これからどうしよう。。。Netlifyでデザイン勉強するか、就活するか。うぅ～ん、
なので、簡単にノートします。これからどんどん書き込んでいきます。
【Indexed View】
- First, create a view that uses the WITH SCHEMABINDING option which binds the view to the schema of the underlying tables.
- Second, create a unique clustered index on the view. This materializes the view.
【Updatable View】
The WITH CHECK OPTION clause is used for an updatable view to prohibits the changes to the view that would produce rows which are not included in the defining query. The following statement creates a view that has rows meet the condition of the WHERE clause.
Updating Updateable Views Using User-Defined Inline Functions←こやつがUpdatable Viewとしたら、
The rules for updating user-defined inline functions are the same as they are for views.
Using INSTEAD OF Triggers to Update Non-Updateable Views←もしやこやつがIndexed Viewなのでは？？？
An INSTEAD OF trigger on a view allows you to get around many of the restrictions on updating views. For example, only one table in a view with multiple joined tables can be updated. An INSTEAD OF trigger can support inserts, updates, and deletes that reference data in more than one table. INSTEAD OF triggers also allow you to code more complex logic than is normally supported in views; and they let you work with time stamp data, computed columns, and identity columns.
【さっさとわかりたい方はこちらからお読みください。そして自己責任で理解するよう努めてください。すみません。。。】
ここにとってもよい情報がのってたけど、このIndexed viewとUpdatable viewの書き分けがされてないから、明日きちんと読みます。
読みました。（二日後）ついでにこちらも合わせて読みました。
https://www.mssqltips.com/sqlservertip/5984/sql-server-trigger-on-view-example/
http://www.informit.com/articles/article.aspx?p=130855&seqNum=4
https://sqlstudies.com/2014/08/06/schemabinding-what-why/
【種類】
Viewを使ってDELTE以外の更新ができるもの➡『Updatable View』
Viewを使って更新ができないもの➡『Non-Updatable View』
【条件】
『Non-Updatable View』
- Any DML statement, must reference columns from only one base table.
- The columns being modified in the view have to directly reference the underlying table columns. As a consequence, the view’s columns being modified cannot be the result of an aggregate function or a computed column.
- Additionally, the columns being modified cannot be affected by GROUP BY, HAVING, or DISTINCT clauses.
- The view’s code must not use the TOP clause together with the WITH CHECK OPTION clause.
- DMLステートメントは、1つのベーステーブルのみから列を参照する必要があります。
- ビューで変更される列は、基になるテーブル列を直接参照する必要があります。 結果として、変更されるビューの列は、集計関数または計算列の結果であってはなりません。
- また、変更される列は、GROUP BY、HAVING、またはDISTINCT句の影響を受けません。
- ビューのコードでは、TOP句とWITH CHECK OPTION句を併用しないでください。
【必要なもの】
『Non-Updatable View』-上記にある『GroupBy』や『Having』なんかを使ってあるView以外にも、パフォーマンスをあげる『Indexed View』なんかはこれに当たります。『Indexed View』に必要なものは『WITH SCHEMABIND』と『Unique Clustered Index』です。これらはリード・オンリーです。通常更新させるために使いません。まぁ、VIEWそのものが更新のためにないものね。
『Schemabinding isn’t a commonly used tool unless you are setting up an indexed view and then it can get lost in the crowd of other required restrictions. It does have uses outside of indexed views however. I could see using it if there is a mission critical view/function that just CAN’T break. By including the SCHEMABINDING clause you protect the view/function from unexpected changes to the tables underneath them. 』『スキーマバインドは、インデックス付きビューをセットアップしない限り、一般的に使用されるツールではありません。そうすると、他の必要な制限の群れで失われる可能性があります。 ただし、インデックス付きビュー以外でも使用できます。 壊れることのないミッションクリティカルなビュー/機能がある場合、それを使用して見ることができます。 SCHEMABINDING句を含めることにより、ビュー/関数をその下のテーブルへの予期しない変更から保護します。』https://sqlstudies.com/2014/08/06/schemabinding-what-why/
でもどうしても更新したいっ！っていう場合には『INSTEAD OF trigger』を使います。
『The only way to make data changes on a non-updateable view is by using INSTEAD OF triggers. This way you can use procedural code to overcome the limitation.』『更新不可のビューでデータを変更する唯一の方法は、INSTEAD OFトリガーを使用することです。 この方法で、手続き型コードを使用して制限を克服できます。 』https://www.mssqltips.com/sqlservertip/5984/sql-server-trigger-on-view-example/
『Updatable View』-Viewは本来直接データにアクセスして更新させるものではありません。ところが、SQLサーバにはなぜかこんな機能が充実されています。今後使っていくうちになぜだかわかることでしょう。。。
まず、『WITH CHECK OPTION』が更新された内容を親テーブルから確認させるために必要です。そして、『InlineUDF』を使った更新も可能です。おぅっ？！Fanctionでは更新できなかったはずなんやけど。。。でも『SELECT』が一つだけの場合、『Updatable Function』ってなるらしいです。（こちらから…もう、わからん。）➡ありました。。。以下をご覧ください。
『Change data is made available to change data capture consumers through table-valued functions (TVFs).』『変更データは、テーブル値関数（TVF）を介してデータキャプチャコンシューマを変更するために利用可能になります。』
では、余談ですがこんな問題があります。
You need to implement the following auditing rules for the Employees table:
– Record any changes that are made to the data in the Employees table.
– Customize the data recorded by the audit operations.
Solution: You implement a user-defined function on the Employees table.
Does the solution meet the goal?
Employeesテーブルに次の監査ルールを実装する必要があります。
– Employeesテーブルのデータに加えられた変更を記録します。
–監査操作によって記録されたデータをカスタマイズします。
解決策：Employeesテーブルにユーザー定義関数を実装します。
ソリューションは目標を達成していますか？
A.yes
B.No
ねこの答えはのーっでした。なぜなら、「by the audit operations」とかいてあったので、監査関係のデータをとるにはDMLトリガーが一番だと思ったからです。
こちらのサイトに処諸々の意見が交換されてます。
http://www.briefmenow.org/microsoft/does-the-solution-meet-the-goal-29/
OLTP（Online Transaction Processing）データベースとは、トランザクション処理を行うことを目的としたデータベースです。トランザクション(Transaction)には2つの意味はあり、英語直訳の「商取引」と、技術用語で「データの一貫性を保つためのデータベースのトランザクション機能」があります。
このOLTPデータベースは、日々増えてくデータを確実に登録し、小さいサイズのデータ取得依頼に対し迅速に応える事に特化しています。また、大量に発生する読書きアクセスに対して同時で実行する機能を持っています。一般的なECサイトやソーシャルゲーム、社内システムではOLTPデータベースであることが多く、データベースの商品名ではORACLEデータベースなどが有名です。
*data warehouse *Non-Clustered Columnstore Index for Analyisis without effect OLTP application. *Momory-Optimized Table
OLAP（Online Analytical Processing）データベースとは、分析処理を行うことを目的としたデータベースです。分析処理とは複数のテーブルなどの情報を繋げ、集計などの分析を行う事です。
OLAPデータベースはOLTPデータベースと対照的に、大量の読書きアクセスに対して同時実行する事には不向きです。また、OLTPデータベースでミリ秒で返ってくるような小さいサイズのデータ取得依頼に対して、OLAPデータベースでは数秒掛かることもあります。しかし、OLAPデータベースは大量データに対しての処理に特化しています。OLTPデータベースで数時間、または処理できない大量データの分析処理でも数分で結果を取得できる事があります。
OLAPデータベースには大規模な機器・施設が必要になることが多く、企業で所有するにはハードルが高いため、最近では Amazon Redshift や Google BigQuery などのクラウドデータベースを時間課金で利用することが一般的になっています。
In fact, an OLTP database is typically constrained to a single application. ... A data warehouse is a database of a different kind: an OLAP (online analytical processing) database. A data warehouse exists as a layer on top of another database or databases (usually OLTP databases)
実際、OLTPデータベースは通常、単一のアプリケーションに制限されています。 ...データウェアハウスは、別の種類のデータベースです：OLAP（オンライン分析処理）データベース。 データウェアハウスは、別のデータベース（通常はOLTPデータベース）の上のレイヤーとして存在します