データベース - ER図 - 版の履歴

Wiki: /* 物理データモデル */

2026-02-05T05:24:58Z

物理データモデル

← 古い版		2026年2月5日 (木) 14:24時点における版
102行目:		102行目:

	__FORCETOC__		__FORCETOC__
	[[カテゴリ:SQL Server]][[カテゴリ:MySQL]]		[[カテゴリ:SQL Server]][[カテゴリ:MySQL]][[カテゴリ:その他データベース]]

Wiki: /* 物理データモデル */

2024-11-10T06:51:30Z

物理データモデル

← 古い版		2024年11月10日 (日) 15:51時点における版
93行目:		93行目:
	<br><br>		<br><br>


			{{#seo:
			\|title={{PAGENAME}} : Exploring Electronics and SUSE Linux \| MochiuWiki
			\|keywords=MochiuWiki,Mochiu,Wiki,Mochiu Wiki,Electric Circuit,Electric,pcb,Mathematics,AVR,TI,STMicro,AVR,ATmega,MSP430,STM,Arduino,Xilinx,FPGA,Verilog,HDL,PinePhone,Pine Phone,Raspberry,Raspberry Pi,C,C++,C#,Qt,Qml,MFC,Shell,Bash,Zsh,Fish,SUSE,SLE,Suse Enterprise,Suse Linux,openSUSE,open SUSE,Leap,Linux,uCLnux,Podman,電気回路,電子回路,基板,プリント基板
			\|description={{PAGENAME}} - 電子回路とSUSE Linuxに関する情報 \| This page is {{PAGENAME}} in our wiki about electronic circuits and SUSE Linux
			\|image=/resources/assets/MochiuLogo_Single_Blue.png
			}}

	__FORCETOC__		__FORCETOC__
	[[カテゴリ:SQL Server]][[カテゴリ:MySQL]]		[[カテゴリ:SQL Server]][[カテゴリ:MySQL]]

Wiki: /* 物理データモデル */

2024-01-25T03:10:42Z

物理データモデル

← 古い版		2024年1月25日 (木) 12:10時点における版
75行目:		75行目:
	ある単一システムを設計する場合に<u>概念データモデル : 論理データモデル＝ 1 : 1</u>であるが、<br>		ある単一システムを設計する場合に<u>概念データモデル : 論理データモデル＝ 1 : 1</u>であるが、<br>
	<u>論理データモデル : 物理データモデル = 1 : N （実装するデータベース製品の種類）</u>という特徴がある。<br>		<u>論理データモデル : 物理データモデル = 1 : N （実装するデータベース製品の種類）</u>という特徴がある。<br>
			[[ファイル:Database ER Diagram 1.png\|フレームなし\|中央]]
	<center>図. データモデルの位置付け</center><br>		<center>図. データモデルの位置付け</center><br>
	<br>		<br>
89行目:		89行目:
	* <u>非機能要件としてのパフォーマンスチューニング」を行う。<u>		* <u>非機能要件としてのパフォーマンスチューニング」を行う。<u>
	<br>		<br>
			[[ファイル:Database ER Diagram 2.png\|フレームなし\|中央]]
	<center>図. データベースを構築するまでの流れ</center><br>		<center>図. データベースを構築するまでの流れ</center><br>
	<br><br>		<br><br>

Wiki: /* 概要 */

2024-01-24T21:57:44Z

概要

← 古い版		2024年1月25日 (木) 06:57時点における版
1行目:		1行目:
	== 概要 ==		== 概要 ==
			一般的に、DAが概念データモデルと論理データモデルを作成して、DBAが物理データモデルを作成する。<br>
			しかし、アプリケーションの規模やプロジェクトの事情によっては、論理データモデルからDBAが担当することもある。<br>
	<br><br>		<br><br>

Wiki: /* 物理データモデル */

2024-01-24T21:57:33Z

物理データモデル

← 古い版		2024年1月25日 (木) 06:57時点における版
80行目:		80行目:
	<br>		<br>
	検索等のパフォーマンスを考慮して、<u>非正規化</u>を行うこともある。 (非正規化は、必ず実施するわけではないことに注意する)<br>		検索等のパフォーマンスを考慮して、<u>非正規化</u>を行うこともある。 (非正規化は、必ず実施するわけではないことに注意する)<br>
			<br>
			物理データモデルの作成において、重要なことを以下に示す。<br>
			* RDBMS全般の知識、製品固有のデータベースの知識を駆使する。
			* <u>インデックス設計</u>を行う。
			* 必要であれば、非正規化を行う。
			* <u>非機能要件としてのパフォーマンスチューニング」を行う。<u>
			<br>

			<center>図. データベースを構築するまでの流れ</center><br>
	<br><br>		<br><br>

Wiki: /* 論理データモデル */

2024-01-24T19:29:34Z

論理データモデル

← 古い版		2024年1月25日 (木) 04:29時点における版
62行目:		62行目:

	要件としてデータベースの実装方式がリレーショナルデータベースであることがあらかじめ判明している場合は、あえて論理データモデルのタイプに階層型やネットワーク型を採用することはない。		要件としてデータベースの実装方式がリレーショナルデータベースであることがあらかじめ判明している場合は、あえて論理データモデルのタイプに階層型やネットワーク型を採用することはない。
			<br><br>

			== 物理データモデル ==
			物理データモデルは、使用する本番環境（ハードウェアも含む）の特性を考慮して論理データモデルを物理データモデルへ変換する。<br>
			<br>
			物理データモデルの設計段階において、初めて、ソフトウェアとしてのデータベースを選定する。<br>
			多くの場合、リレーショナルデータベースが採用されるため、Oracleデータベース、SQL Server、MySQL等の具体的なRDBMSへの実装を目的とした物理データモデルを作成する。<br>
			<br>
			したがって、物理データモデルは各データベース製品の機能に依存するため、<br>
			ある単一システムを設計する場合に<u>概念データモデル : 論理データモデル＝ 1 : 1</u>であるが、<br>
			<u>論理データモデル : 物理データモデル = 1 : N （実装するデータベース製品の種類）</u>という特徴がある。<br>

			<center>図. データモデルの位置付け</center><br>
			<br>
			<u>物理データモデルの作成では、データ型の定義、ビューの定義、インデックス設計および定義、各種のパラメータ設定等の物理的な環境に依存した物理データモデルを作成する。</u><br>
			<u>また、非機能要件としてのパフォーマンスチューニング等（データ容量、表領域の計算）の調整もここで行う。</u><br>
			<br>
			検索等のパフォーマンスを考慮して、<u>非正規化</u>を行うこともある。 (非正規化は、必ず実施するわけではないことに注意する)<br>
	<br><br>		<br><br>

Wiki: /* 論理データモデル */

2024-01-24T19:16:11Z

論理データモデル

← 古い版		2024年1月25日 (木) 04:16時点における版
51行目:		51行目:
	※備考		※備考

	論理データモデルはデータベースの実装方式とは独立している。~~<br>~~		論理データモデルはデータベースの実装方式とは独立している。

	論理データモデルをリレーショナル型で作成することと、データベースの実装方式としてリレーショナルデータベースを採用することは等価ではない。~~<br>~~		論理データモデルをリレーショナル型で作成することと、データベースの実装方式としてリレーショナルデータベースを採用することは等価ではない。
	あくまでも、論理データモデルのデータ構造の表現形式の1つとしてリレーショナル型があり、論理データモデルは実装方式には依存せず、独立した関係にある。		あくまでも、論理データモデルのデータ構造の表現形式の1つとしてリレーショナル型があり、論理データモデルは実装方式には依存せず、独立した関係にある。

Wiki: /* 概念データモデル */

2024-01-24T19:15:26Z

概念データモデル

@@ 26行目: / 26行目: @@
 <br>
 ER図では、「意味的な集まり」を「エンティティ」と呼び、「グループ間の関連付け」を「リレーションシップ」と呼ぶ。<br>
 <br><br>

Wiki: ページの作成:「== 概要 ==

== 概念データモデル == 概念データモデルは、対象業務の現実の世界を対象としており、
「データにはどのような意味があるのか？」という視点から、意味的な集まりを見いだすことでグループ化、およびグループ間の関連付けを行い、概念データモデルを作成する。

実際には、ユーザからの要求や既存システムの画…」

2024-01-24T19:02:48Z

ページの作成:「== 概要 == == 概念データモデル == 概念データモデルは、対象業務の現実の世界を対象としており、 「データにはどのような意味があるのか？」という視点から、意味的な集まりを見いだすことでグループ化、およびグループ間の関連付けを行い、概念データモデルを作成する。 実際には、ユーザからの要求や既存システムの画…」

新規ページ

== 概要 ==
 

== 概念データモデル ==
概念データモデルは、対象業務の現実の世界を対象としており、 
「データにはどのような意味があるのか？」という視点から、意味的な集まりを見いだすことでグループ化、およびグループ間の関連付けを行い、概念データモデルを作成する。 
 
実際には、ユーザからの要求や既存システムの画面や帳票等からデータ項目を洗い出して、 
アプリケーションの範囲やシステムの範囲ではなく、業務の中で扱っている全てのデータを扱う。（コンピュータで記憶されるデータ以外のものも含める） 
 
概念データモデルは、決して概念レベルのものを扱っているだけではない。 
既存システムの画面や帳票等からデータ項目を洗い出すのは、業務機能が変更されてもそこで扱われるデータは継続して利用される場合がほとんどだからである。 
これが、データを中心にして考えるメリットである。 
 
例えば、製造業のシステムを開発することが目的での場合においても、製造業のシステム領域以外のデータであれば他の会計システムや生産管理システムも扱うデータの対象となる。 
他のシステムとのインターフェイスまで含めた広い範囲のモデルを構築することが重要である。 
 
その方法として、既存システムの画面や帳票等からデータを集めること（ボトムアップアプローチ）は必要であるが、 
経営層まで参画させて、企業として将来像（ゴール）を決定すること（トップダウンアプローチ）も必要である。 
 
将来像が決定すれば、自ずと必要なデータも見えるからである。 
たとえデータモデルが安定している場合でも、データのライフサイクルが短いのでは元も子もない。 
企業の変革のスピードが速い時代だからこそ、先を見据えた安定的なデータモデルの構築が企業競争力に繋がるといえる。 
 
概念データモデルを作成する場合は、ER図（ERD ： entity-relationship diagram）が用いられることが多く、概念データモデルを表現したER図は概念ER図と呼ばれる。 
 
ER図では、「意味的な集まり」を「エンティティ」と呼び、「グループ間の関連付け」を「リレーションシップ」と呼ぶ。 
 

__FORCETOC__
[[カテゴリ:SQL Server]][[カテゴリ:MySQL]]