Microsoftは今回の発表で、この拡大は「世界的に一貫したライセンスは、顧客にとっての明確性を確保し、意思決定と交渉を合理化するのに役立」つと説明する。
ただし、既存の顧客は現在のライセンス契約を継続できる。
新規顧客の場合、Teamsなしの365製品と（必要であれば）単体Teamsを購入することになる。米国でのエンタープライズスイートの価格は以下の通り（本稿執筆現在、日本での販売価格はまだ発表されていない）。
⇧ コミュニケーションツールの部分に、他社製品を利用する選択肢が取れるようになったのは良いのだけど、
- Teamsありの365製品
→既存契約 - Teamsなしの365製品と（必要であれば）単体Teams
→新規契約
既存の時より価格が上がってるとしたら、既存顧客の囲い込みをしてることになる気がするからして、「独占禁止法」の部分が解消されない気がするんだが...
再契約時は、価格が上がりますよ、って言われたら、顧客としては、契約維持し兼ねない気持ちになることが多そうですし...
一応、
なお、この変更は商用製品にのみ適用されるもので、一般ユーザー、学術、政府向け、非営利団体向け製品は影響を受けない。
⇧ とは言ってますが、モヤモヤしますな...
テーブル設計におけるスーパータイプとサブタイプって？
Wikipediaさんによりますと、
An entity–relationship model (or ER model) describes interrelated things of interest in a specific domain of knowledge. A basic ER model is composed of entity types (which classify the things of interest) and specifies relationships that can exist between entities (instances of those entity types).
In software engineering, an ER model is commonly formed to represent things a business needs to remember in order to perform business processes. Consequently, the ER model becomes an abstract data model, that defines a data or information structure which can be implemented in a database, typically a relational database.
Entity–relationship modeling was developed for database and design by Peter Chen and published in a 1976 paper, with variants of the idea existing previously, but today it is commonly used for teaching students the basics of data base structure. Some ER models show super and subtype entities connected by generalization-specialization relationships, and an ER model can be used also in the specification of domain-specific ontologies.
⇧ とあることから、
「汎化-特化」は、一言で「汎化（generalization）」といわれるモデリング技法です。「継承」といえばお分かりですよね。継承は汎化の実現手段の1つなのです。
⇧「モデリング」が起源ってことになるんかね？
⇧ その中の「データモデリング」の説明を見に行くと、
データモデリング（英: data modeling）は、コンピュータ科学の文脈では、何らかのデータモデリング方法論を適用してデータモデルのインスタンスを作る過程である。 データモデリング方法論は、データモデリングを形式的に記述したものである。 現在までに考案されたデータモデルの種類としては、次のようなものがある。
データモデリングの例については、次の節を参照。
⇧ とあるので、「ER図」は「データモデリング」の1つに当たると。
「ER図」と「UML」は別物ってことになるみたいね。
話が脱線しましたが、「generalization-specialization（汎化-特化）」の具体例として、
汎化-特化は、白抜きの矢印で表します。矢印の指している方を「スーパークラス」、その逆を「サブクラス」と呼びます。図の上下左右の位置関係は関連と同様に関係ありません。
図4では、次のことをモデルにて表現しています。
- 複数の社員は会社で働く
- 社員には営業員と技術員がいる
つまり、このモデリングでは、営業員と技術員をまとめた抽象的なクラスである社員を導入し、会社と社員という関係をシンプルに示すことが可能になります。このように抽象的なクラス（社員）をモデルに入れることで「営業員と技術員は社員という特性を共有する」という概念の整理がスムーズに行えていることに注目してください。
⇧ 上記のような「継承」が行われることになり、その時に登場するのが、
- スーパークラス
- サブクラス
で、このモデリング技法をテーブル設計に当てはめた場合に、
- スーパータイプ
- サブタイプ
という用語になるということらしい。
テーブル設計でスーパータイプとサブタイプに分けるメリット・デメリットを知りたかったんだが...
で、テーブル設計でスーパータイプとサブタイプに分けるメリットが分からんのだが、と思っていたのですが、海外でも同様の疑問を抱いていた方がおられて、
The advantages are that supertypes allow us to unify common attributes, relationships and integrity for multiple entity sets, while subtypes allow us to support type-specific attributes, relationships and integrity constraints. This allows us to simplify the database and our queries and enforce tighter integrity.
In your first example, we would need to query each of the 3 tables separately if we wanted to know when all accounts were opened or reviewed. If we wanted to establish a relationship between accounts and customers, we would need 3 separate relationships, and 3 separate queries to get all customers and accounts. Constraints like ensuring review dates occurred after opening dates would have to be defined 3 times.
Without subtypes, we would need to support all possible attributes and relationships for a single common type, and our queries would have to include type-specific logic to handle different rows separately. We could not easily enforce type-specific constraints, like positive interest rates which don't apply to checking accounts.
https://stackoverflow.com/questions/41814377/what-are-the-benefits-of-super-type-sub-type-table
⇧ という説明なのだけど、1つ気になるのは、
- スーパータイプ
- サブタイプ
に分けるということは、登録されるレコード数は単純に2倍になると思うんだけど、そのあたりのデメリットは言及されていなんよな...
何やら、
The names of these three models come from Martin Fowler's book Patterns of Enterprise Application Architecture.
https://stackoverflow.com/questions/41814377/what-are-the-benefits-of-super-type-sub-type-table
⇧「マーティン・ファウラー」氏の著書で紹介されてるらしいエンタープライズ系のアプリケーションのアーキテクチャのパターンが由来と紹介しているっぽいのだけど、デメリットについては明確に触れられていない...
とりあえず、デメリットとしては、
- テーブルの数が増える
- レコード数が2倍になる
あたりになってくるのかな？
排他的サブタイプと共存的サブタイプ、その他いろいろ
で、「サブタイプ」にはいろいろなパターンが有り得るらしく、
⇧ 上記サイト様が解説してくれています。
何と言うか、このあたり、「独立行政法人情報処理推進機構（IPA：Information-technology Promotion Agency, Japan）」が「サブタイプ」のパターンを「MECE（Mutually Exclusive, Collectively Exhaustive）」に整理して公開して欲しいものなのだが、全く整理してくれていないのよね...
まぁ、
独立行政法人情報処理推進機構（じょうほうしょりすいしんきこう、英: Information-technology Promotion Agency, Japan、略称: IPA）は、日本のIT国家戦略を技術面・人材面から支えるために設立された独立行政法人（中期目標管理法人）。所管官庁は経済産業省。
⇧ と謳うのであれば、もう少し頑張って欲しいんだが...
結局のところ、テーブル設計で「スーパータイプ」「サブタイプ」を考慮すべきかどうかが分からんですな...
「独立行政法人情報処理推進機構（IPA：Information-technology Promotion Agency, Japan）」としては、試験に出してるぐらいだから推奨してるのだと思うのだけど、実際の現場でテーブル設計で「スーパータイプ」「サブタイプ」を導入してるプロジェクトを見たこと無いんだよな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
