6.1.1 データベースの設計 [데이터베이스의 설계] #
データベースの設計手順[데이터베이스의 설계 순서] #
データベースの設計は，「概念設計→論理設計→物理設計」の順に行われます。
데이터베이스의 설계는, 「개념설계→논리설계→물리설계」의 순서로 이루어진다.
그림 6.1.1 데이터베이스 설계의 흐름
概念設計[개념 설계] #
概念設計では，対象とする実世界のデータすべてを調査・分析して，抽象化した概念データモデルを作成します。概念データモデルは，コンピュータへの実装を意識せずに，単にデータのもつ意味とデータ間の関連をあるがままに表現することに重点がおかれたデータモデルです。そのため，概念データモデルの作成には，特定のDBMS（DataBase Management System：データベース管理システム）に依存せずにデータ間の関連が表現できるE-R図やUMLのクラス図が用いられます。
개념 설계에서는, 대상으로 하는 실세계의 데이터 전체를 조사・분석해, 추상화한 개념 모델을 작성한다. 개념 데이터 모델은, 컴퓨터로의 실장(구현)을 의식하지 않고, 단순히 데이터가 가진 의미와 데이터 간의 관련성을 있는 그대로 표현하는 것에 중점을 둔 데이터 모델이다. 따라서, 개념 데이터 모델의 작성에는 특정한 DBMS(DataBase Management System : 데이터베이스 관리 시스템)에 의존하지 않고 데이터 간의 관련성을 표현 가능한 E-R 다이어그램이나 UML의 클래스 다이어그램이 사용된다.
データ分析[데이터 분석] #
概念設計のデータ分析では，業務で使用されている帳票や伝票，画面などを調査して，どのようなデータ項目があるのか，どのデータ項目が必要なのか，そのすべてを洗い出します。そして，洗い出されたデータ項目を一定の基準に従って標準化し（データ項目の標準化），異音同義語や同音異義語を排除します。また，各データ項目の関連を整理して正規化を行い，複数箇所に存在する同一データ項目（重複項目）を排除します。
개념 설계의 데이터 분석에서는, 업무에 사용되고 있는 장표나 전표, 화면 등을 조사해, 어떤 데이터 항목이 있는지, 어떤 데이터 항목이 필요한지, 그와 관련된 모든 것을 구체적으로 밝혀낸다. 그리고, 도출된 데이터 항목을 일정한 기준에 따라 표준화해(데이터 항목의 표준화), 이음동의어나 동의이음어를 배제한다. 또한, 각 데이터 항목의 관련성을 조정해 정규화를 이행하고, 여러 곳에 존재하는 동일 데이터 항목(중복항목)을 배제한다.
データ項目の標準化と定義(데이터 항목의 표준화와 정의) #
- データ項目名の標準化[데이터 항목명의 표준화]
- データ項目の意味の定義[데이터 항목의 의미의 정의]
- データ項目の桁数や型（タイプ）の統一[데이터 항목의 자리수와 형(타입의 통일)]
- 各データ項目の発生源や発生量の明確化[각 데이터 항목의 발생원이나 발생량의 명확화]
トップダウンアプローチとボトムアップアプローチ(탑다운 접근법과 바텀업 접근법) #
データの分析手法には，画面や帳票などから項目を洗い出し，データ分析を行った結果として現実型の概念データモデルを作成するボトムアップアプローチと，最初に理想型の概念データモデルを作成してからデータ分析を行うトップダウンアプローチの2つがあります。いずれのアプローチによっても，最終的に作成されるデータモデルは，正規化され，かつ，業務上必要なデータ項目をすべて備えていなければなりません。
トップダウンアプローチかボトムアップアプローチのいずれかのみで分析・設計を行うのではなく，例えば，ボトムアップアプローチで作成したものをトップダウンアプローチで見直すなど，業務に応じた適切な方法を用いることが重要です。
데이터의 분석방법에는, 화면이나 장표 등에서 항목을 도출해, 데이터 분석을 이행한 결과로써 현실적인 개념 데이터모델을 작성하는 바텀업 접근법과, 최초에 이상적인 개념 데이터 모델을 작성한 다음 데이터 분석을 이행하는 탑다운 접근법으로 2가지가 있다. 어떤 접근법에도, 최종적으로 작성되는 데이터 모델은, 정규화 및 업무상 필요한 데이터 항목을 모두 갖춰야만 한다.
톱다운 접근법 또는 바텀업 접근법 중 어느 하나만을 활용해 분석・설계를 하는것이 아니라, 예를 들어, 바텀업 접근법으로 작성한 것을 톱다운 접근법으로 재점검하는 등, 업무에 따른 최적의 방법을 사용하는 것이 중요하다.
論理設計[논리 설계] #
E-R 図やUMLのクラス図で表現された概念データモデルは，必ずしもデータベースに実装できる表現になっていません。そこで，概念データモデルを，データベースに実装できる形式，すなわち論理データモデルに変換します。
E-R 다이어그램이나 UML의 클래스 다이어그램으로 표현된 개념 데이터모델은, 절대로 데이터베이스에 구현 가능한 표현으로 되어 있지 않다. 따라서, 개념데이터모델을, 데이터베이스에 구현 가능한 형식, 즉 논리 데이터모델로 변환한다.
論理データモデル[논리 데이터 모델] #
論理データモデルは，データベース構造モデルとも呼ばれるデータモデルです。利用者とデータベース間のインタフェースの役割を担うデータモデルであるため，どのデータベースを用いて実装するかによって，用いられる論理データモデルが異なります。
논리 데이터 모델은, 데이터베이스 구조 모델이라고도 불리는 데이터 모델이다. 이용자와 데이터베이스 간의 인터페이스의 역할을 담당하는 데이터 모델이기에, 어떤 데이터베이스를 사용해 구현하는지에 따라, 사용되는 논리 데이터 모델이 다르다.
論理データモデルの種類と特徴[논리 데이터 모델의 종류와 특징] #
- 階層モデル[계층 모델]
- 階層型データベースの論理データモデル
- 階層構造（木構造）でデータの構造を表現する。親レコードに対する子レコードは複数存在しうるが，子レコードに対する親レコードはただ1つだけという特徴がある。このため，親子間の“多対多”の関係を表現しようとすると冗長な表現となる
- [계층형 데이터 베이스의 논리 데이터 모델]
- 계층 구조(트리 구조)로 데이터의 구조를 표현한다. 부모 레코드에 대응하는 자식 레코드는 복수 존재할 수 있으나, 자식 레코드에 대응하는 부모 레코드는 단 1개라는 특징이 있다. 따라서, 부모-자식 간의 “다대다” 관계를 표현하고자 하면 장황한 표현이 된다.
- 網モデル[망(네트워크) 모델]
- 網（ネットワーク）型データベースの論理データモデル
- レコード同士を網構造で表現する。親子間の“多対多”の関係も表現できる。ネットワークモデルともいう
- [망(네트워크)형 데이터베이스의 논리 데이터 모델]
- 레코드끼리의 망 구조로 표현한다. 부모-자식 간의 “다대다” 관계도 표현할 수 있다. 네트워크 모델이라고도 한다.
- 関係モデル[관계 모델]
- 関係型データベースの論理データモデル
- データを2次元の表（テーブル）で表現する。1つの表は独立した表であり，階層モデルや網モデルがもつ親レコードと子レコードという関係はもたない
- [관계형 데이터베이스의 논리 데이터 모델]
- 데이터를 2차원의 표(테이블)로 표현한다. 1개의 표는 독립된 표이며, 계층 모델이나 망 모델이 가지는 부모 레코드와 자식 레코드라는 관계는 가지지 않는다.
関係モデルへの変換[관계 모델로의 변환] #
関係データベースを用いて実装する場合，概念データモデルを基に，主キーや外部キーを含めたテーブル構造を作成します。その際，テーブルの各列（データ項目）に設定される非NULL制約や検査制約などの検討も行います。非NULL制約とは空値（NULL）の登録を許可しないという制約，検査制約は登録できるデータの値や範囲を設定する制約です
また，個々のアプリケーションプログラムや利用者が使いやすいようにビューの設計（定義）を行うのもこの段階です。
관계 데이터 베이스를 사용해 구현할 경우, 개념 데이터 모델을 기반으로, 기본키와 외래키를 포함한 테이블 구조를 작성한다. 그 경우, 테이블의 각 열(데이터 항목)에 설정된 비 NULL 제약이나 검사 제약 등의 검토도 이행된다. 비 NULL 제약이란 없는/알 수 없는 값(NULL)의 등록을 허가하지 않는다는 제약이며, 검사 제약이란 등록 가능한 데이터의 값이나 범위를 설정하는 제약이다.
또한, 각각의 어플리케이션 프로그램이나 이용자가 사용하기 쉽도록 뷰의 설계(정의)를 이행하는 것도 이 단계이다.
物理設計[물리 설계] #
物理設計は，データベースに要求される性能を満たすための設計です。データの量や利用頻度，さらに運用面も考慮して，最適なアクセス効率及び記憶効率が得られるよう，データベースの物理的構造を設計します。具体的には，ディスク容量の見積り，ブロック長やインデックス（索引）の設計，そして，アクセス効率の向上を図るための表の分割や複数ディスクへの分割の検討も行います。なお，物理設計の結果，十分な性能が得られないと判断された場合，論理設計に戻ってデータ構造の再検討（例えば，正規化によって分割された表を結合する非正規化）を行います。
물리 설계는, 데이터베이스에 요구되는 성능을 충족시키기 위한 설계이다. 데이터의 양이나 이용빈도, 더 나아가 운용 면도 고려해, 최적의 접근 효율 및 기억 효율을 취할 수 있도록, 데이터베이스의 물리적 구조를 설계한다. 구체적으로는 디스크 용량의 견적, 블록 길이나 인덱스(색인)의 설계, 그리고 접근 효율의 향상을 도모하기 위한 표의 분할이나 복수 디스크로의 분할의 검토도 실시한다.
6.1.2 データベース設計における参照モデル[데이터베이스 설계에서의 참조 모델] #
3層スキーマ構造(3층 스키마 구조) #
3層スキーマ構造（3層スキーマアーキテクチャともいう）は，データベース設計における参照モデルです。 データベースは，環境の変化や時間の経過とともに実世界が変わると，少なからずその影響を受け，変更を余儀なくされることもあります。このような変更の多くは，データベース内のデータを変更することで対応ができますが，場合によってはデータ構造や物理的な格納構造の変更が必要な場合もあります。 そこで，データベースの構造を変更しても，その影響をアプリケーションプログラムが受けないようにするために，データの記述及び操作を行うための枠組み（スキーマ）を，外部，概念，内部の3層に分けて管理しようと考えられたのが3層スキーマ構造です。表6.1.2及び次ページの図6.1.3に示す3つのスキーマから構成され，これによりデータの独立性を確保します。
3층 스키마 구조(3층 스키마 아키텍처라고도 한다)는, 데이터베이스 설계에서의 참조 모델이다.
데이터베이스는, 환경의 변화나 시간의 경과에 따라 실세계가 변하면, 적지 않게 그 영향을 받아, 갱신(변경)을 어쩔 수 없이 하게 되는 경우도 있다. 이와 같은 갱신의 많은 경우는, 데이터베이스 내의 데이터를 갱신하는 것으로 대응이 가능하지만, 경우에 따라서는 데이터의 구조나 물리적인 격납구조의 갱신이 필요한 경우도 있다.
따라서, 데이터베이스의 구조를 갱신하더라도, 그 영향을 어플리케이션 프로그램이 받지 않도록 하기 위해, 데이터의 기술 및 조작을 행하기 위한 틀(스키마)을, 외부, 개념, 내부의 3층으로 나눠 관리하고자 생각된 것이 3층 스키마 구조이다. 표 6.1.2 및 그림 6.1.3에 표시된 3개의 스키마로부터 구성되어, 이것에 의해 데이터의 독립성을 확보한다.
