빈집 채우는 중

데이터베이스 디자인과 그 이행 단계:

Entity: 존재하고 다른 객체와 구분할 수 있는 객체

Attribute: 객체의 성질(특성)

Relationship: 여러 엔티티 간의 관련성

DB 디자인에 High-level 개념 데이터 모델 사용

1.     필요 조건 분석 및 모으기:

-       DB 설계자와 application programmers는 예상 DB 사용자들을 인터뷰하여 그들의 데이터와 요구 Operations를 이해하고 문서화한다. 이 사용자 요구사항들은 가능한 한 자세하고 완전하게 정의되어야 한다.

-       Requirements specification techniques: 사용자 요구, 용어집, 클래스 다이어그램, 데이터 흐름도, use case diagram 등을 분석한다.

2.     개념적 데이터베이스 디자인:

-       개념적 스키마 디자인: 1단계에서의 결과를 토대로 필요한 데이터를 조사하고 ER 다이어그램 같은 개념적인 DB 스키마를 만들어낸다.

-       트랜잭션과 Application 디자인: 정리된 DB application을 조사하고 input과 output을 구분하고 DB applications나 트랜잭션의 기능에 대한 High-level specification을 만든다.

3.     DBMS 선택: 기술적, 경제적, 정책적인 요소들을 고려한다.

4.     논리적 데이터베이스 디자인: 2단계의 개념 스키마를 선택한 DBMS의 데이터 모델에 적용한다. 많은 자동화된 CASE 디자인 도구들은 개념 스키마 디자인을 통해서 DDL을 생성해낼 수 있다. ANSI/SPARC three-level DBMS 아키텍쳐에서는 이 단계의 결과가 특정 application을 위한 개념적 스키마와 외부 스키마이다.

5.     물리적 데이터베이스 디자인: 내부 저장소 구조, 파일 조직, 인덱스들, 접근 경로(Access paths), 그리고 DB 파일을 위한 물리적 설계 매개변수(Physical design parameters)들을 지정한다. 반응 시간, 공간 활용, 트랜잭션 처리량은 실제 데이터베이스 디자인 옵션을 선택하는데 사용되는 기준(Creteria)이다. 이 단계에서 three-level DBMS 아키텍쳐의 용어에서 내부 스키마를 설계한다.

6.     데이터베이스 시스템 구현 및 튜닝: 이 단계는 보통 DBA가 맡고 DB 설계자와 함께 수행한다. DDL을 작성하고 이전 시스템으로부터 데이터를 이전하며, 선택된 DBMS의 DDL/SDL들이 DB 스키마와 DB 파일들을 만들기 위해 컴파일되면, DB는 이제 데이터를 로드 할 수 있다. DML을 포함한 DB 프로그램들은 application programers가 구현한다. DB의 튜닝은 성능적 문제가 발견되면 계속되며, 그 동안 요구 사항이 지속적으로 변한다.

샘플 DB Application

ER 다이어그램 표기법: 사각형은 어떤 종류의 추상화된 객체인 엔티티를 나타낸다. 다이아몬드는 여러 엔티티 간의 연관 관계를 나타낸다. 엔티티 또는 관계에 직선으로 연결된 타원은 속성(Attribute)를 나타낸다. 밑줄은 Primary key attributes임을 가리킨다.

이런 ER 다이어그램은 어떤 직원이 프로젝트들에 참여하고 있고 관리하는 지에 대한 회사의 정보를 보여준다.

필요 데이터: COMPANY 데이터베이스는 회사의 직원, 부서, 그리고 프로젝트를 가지고 있다.

엔티티와 속성

엔티티: 독립적으로 존재하는 실제 세상의 물건. 물리적 혹은 개념적으로 존재하는 객체.

속성(Attributes): 엔티티를 설명하기 위한 부분적인 속성. 단순/합성 속성, 단일 값/다중 값 속성, 저장된/파생된 속성(다른 속성으로 컴퓨팅 될 수 있는 속성), 복잡한 속성(합성 속성과 다중 값 속성은 임의로 중첩될 수 있다.).

Entity Types, Sets, Keys, Value sets

Entity type: 스키마 또는 동일한 구조를 공유하는 엔티티 집합을 위한 의도. DB에 있는 각 entity type은 이름과 속성으로 설명되어 있다. Entity type은 ER 다이어그램에서 엔티티 타입의 이름이 적힌 사각형 상자로 표현된다.

Entity set: Entity type의 확장. 어떤 한 시점에서 일부 entity type의 모든 엔티티의 모음이다. Entity set은 주로 entity type의 이름과 같은 이름을 사용하여 참조된다.

Key attribute: 엔티티 타입에서 각각을 구분할 수 있는 값을 가지는 속성을 말한다. 복합 키(Composite key)는 여러 간단한 구성 요소 속성을 가지는 키이다. ER 도식화 표현법에서, key attribute는 타원 안쪽의 이름에 밑줄이 쳐져 있다.

어떤 엔티티 타입은 하나 이상의 key attribute를 가지기도 한다. 또한, key를 가지지 않기도 하는데, 이럴 경우를 weak entity type이라고 한다.

Relationship Types, Sets, and Instances

Relation: 한 엔티티 타입의 한 속성이 다른 엔티티 타입을 참고할 때, 관계(Relationship)이라고 한다. 속성이 아닌 관계로 참조를 표시하며, 일반적으로 요구 사하에 두 개 이상의 엔티티 간의 논리적 연결을 제공하는 개념이 포함된 경우에 사용한다.

Relationship type R among n entity types: 엔티티 타입들로부터 엔티티 간의 연관성 집합을 정의한다. ER 다이어그램에서, relation types은 다이아몬드 모양으로 표현된다.

Relationship set R is a set of relationship instances r: 각 r은 각각의 엔티티들과 연관시킨다. R에 있는 엔티티 e는 entity set E의 멤버이다.

Relationship Degree, Role Names and Recursive Relationship

Degree of a relationship type: 관여하고 있는 entity type의 개수. Binary, ternary 등이 있다. SUPPLY라는 relationship set은 relationship 인스턴스들의 집합이다.

Relationships as attributes: 가끔은 속성의 관점에서 생각하면 이진 관계 유형(binary relationship type)이 생각하기 편리할 수 있다. 하지만, 이진 관계 유형을 속성으로 생각하면, 우리는 언제나 2가지 선택지만 주어지게 된다. 예를 들어, WORKS_FOR relationship type은 오직 ‘Employee entity type의 Department attribute’ 혹은 ‘Department entity type의 Employee attribute’로만 표현할 수 있게 된다.

Role names: Relation type에 관여하고 있는 각 entity type은 관계에서 부분적인 역할을 맡는다. 역할 이름은 관여하고 있는 엔티티가 각 관계 인스턴스에서 역할을 의미하고, 이 relationship이 의미하는 것을 설명하는 것을 돕는다. Role names는 모든 관여하는 entity types가 뚜렷한 relation types에겐 필요하지 않다. 각 관여하는 entity type의 이름은 role name으로 사용 될 수 있기 때문이다.

Recursive relationships: 같은 엔티티 타입이 한 번 이상 하나의 relation type에 다른 역할로 관여할 때이다. 이럴 때는 role name을 명시해야만 한다.

Constraints on Binary Relationship Types

Relationship types는 주로 상응하는 relationship set에 관여가 가능하도록, 가능한 엔티티 조합을 제한하는 특정한 제약들을 가진다.

이진 관계를 위한 Cardinality ratio: 엔티티가 관여할 수 있는 relationship instance의 최대 개수를 지정한다. 이진 관계에서 가능한 Cardinality ratio들로는 1:1, 1:N, M:N이 있다.

참여 제약 조건 및 존재 종속성: Relationship type을 통해 하나의 엔티티가 존재하는 것을 다른 엔티티와 관련되도록 지정한다. Total participation(두 줄)과 partial participation(한 줄)로 나뉜다. Total participation은 존재 종속성이라고 불리기도 한다.

Attributes of Relationship Types

Relationship types 또한, 엔티티와 비슷하게 속성을 가질 수 있다. 1:1 혹은 1:N relationship types의 속성은 하나의 entity type에 마이그레이션 할 수 있다. 1:1 relationship type에서는 아무 entity type에 마이그레이션이 가능하다. 1:N relationship type에서는 N에 해당하는 엔티티에게만 마이그레이션이 가능하다. 하지만 M:N relationship type의 특성은 relationship의 특성으로 정의되어야만 한다.

Weak Entity Types

Primary key가 존재하지 않는 entity type이다. 다른 엔티티가 존재하는 것에 엔티티의 존재가 의존한다.

Weak entity type의 존재는 identifying entity type(혹은 owner entity type)의 존재에 의존한다. Weak entity type은 구분하기 위해서 identifying entity type과 총체적으로(existence dependency) 그리고 1:N relation type으로 연관되어야만 한다. Weak entity type과 이를 구분하는 relationship은 두 줄로 된 박스와 다이아몬드 모양으로 구분할 수 있다.

Weak entity type의 discriminator(혹은 partial key)는 weak entity type의 모든 엔티티를 구분해주는 속성의 집합이다. Discriminator는 점선으로 밑줄을 그어 표시한다. Weak entity type의 primary key는 identifying entity type의 primary key와 weak entity type의 discriminator의 합으로 생성된다.

Weak entity types는 가끔 복합(조합, 다중 값) 특성으로 표현될 수 있다. 어떤 표현을 사용할 것인지에 대한 선택은 DB 설계자한테 있다. 사용할 수 있는 한 표준은 만약 어떤 것이 많은 속성을 가지고 있다면 weak entity type 표현을 선택하도록 하고 있다. 만약 weak entity가 독립적으로 그것의 identifying relationship type보다 relationship type에 관여한다면, 그것은 복합 속성으로 모델링 되어서는 안된다.

ER 설계를 위한 디자인 선택

어떤 부분적인 개념을 entity type으로, 속성으로, 혹은 relationship type으로 할 것인지 결정하는 것은 어려운 일이다. 일반적으로, 스키마 설계 과정은 가장 알맞은 설계에 도달할 때까지 반복적인 Refinement process로 간주 되어야한다.

자주 사용되는 Refinement process는 다음을 포함한다:

-       개념은 속성으로써 가장 먼저 모델링 되어야한다. 만약 속성이 다른 entity type에 참고되면 relationship으로 재정의한다.

-       여러 entity types에 존재하는 속성들은 독립적인 entity type으로 만들 수 있다.

데이터베이스 설계 과정:

-       요구 사항을 모아서 설명을 붙인다.

-       Entity type을 구분해낸다. (명사)

1.     모은 요구사항으로 만든 설명에서 명사를 분리한다.

2.     잘못 정의되거나 너무 광범위한 개념을 제외한다.

3.     생략된 entity type이 있는지 확인한다.

-       Relationship types를 구분한다. (동사)

-       Relationship type을 1:1인지, 1:N인지, 아니면 M:N인지 결정한다.

-       ER 스키마 다이어그램을 그린다.

-       Entity types와 Relation types에 필요한 속성들을 구분한다. (명사 혹은 형용사)

-       Entity types의 primary key를 구분한다.

-       ER 스키마 다이어그램이 요구 사항을 충족시키는지 확인한다.

-       DBMS에서 사용되는 적절한 데이터 모델에 ER 스키마 다이어그램을 매핑한다.

ER 다이어그램의 대체 표기법

한 ER 대체 표기법은 Relationship type R에 대한 entity type E의 관계를 한 쌍의 정수 (Min, Max)를 연관시킨다. 숫자들은 entity set E의 각 e에 대해서, e는 적어도 min에서 최대 max개의 relationship instances에게 영향을 미쳐야 한다. Min=0이면 partial participation이고, min>0이면 total participation이다.

UML Class Diagrams

UML(Unified Modeling Language) 방법은 소프트웨어 설계에 광범위하게 사용되고 있으며, 다양한 소프트웨어 설계 목적을 위한 다양한 유형의 다이어그램을 가지고 있다. Class diagram, Object diagram, Deployment diagram 등이 있는 구조적인 다이어그램과 Use Case diagram, Sequence diagram, Activity diagram 등이 있는 행동적인 다이어그램이 있다.

Class Diagram: 다른 엔티티들이 서로에게 어떻게 연관되어 있는지 보여준다. 다른 말로, 시스템의 정적인 구조를 보여준다. 시스템 내의 클래스, 속성, operations와 각 클래스 간의 relationship(association, aggregation 등)을 포함한다. 클래스는 3개의 부분으로 나뉘어 사각형으로 묘사된다. 가장 위쪽 부분은 클래스의 이름을, 중간 부분은 클래스의 특성을, 아래 부분은 클래스의 Operations를 포함한다. 집합(Aggregation)은 모든 객체와 그 구성하는 부분 간의 관계를 보여주는 것을 의미한다.

Relationship Types of Degree Higher than Two

Degree of a relationship type: 관련 있는 entity types의 개수. Binary, ternary 등이 있다. 일반적으로, n-ary relationship은 n binary relationships와 같지 않다.

일부 DB 설계 도구들은 오직 binary relationships만 지원한다. 이럴 경우, ternary relationship은 partial key와 three identifying relationship가 없이 weak entity type으로 표현되어야 한다.

Artificial 혹은 surrogate key를 도입하는 것으로, ternary relationship을 regular entity type인 것처럼 표현할 수 있다. 아래 예시의 경우, key attribute인 Supply_id는 regular entity type으로 변환하는 것으로 supply entity type으로 사용될 수 있다.

데이터 모델, 스키마, 인스턴스

데이터 모델(DB 모델): describing data, 데이터 관계, 데이터 시맨틱, 그리고 데이터 제약을 위한 추상화 도구들의 집합이다. (그래서 어느 정도의 데이터 추상화를 제공한다.) 대부분의 데이터 모델들은 DB에서의 검색과 업데이트를 지정하기 위한 기본적인 operations의 모음을 제공한다.

데이터 모델은 일반적으로 Structure of the data, Operations on the data, Constraints on data로 구성된다.

Relational Model에서:

-       Structure of the data: Table

-       Operations on the data: insert, delete, update와 같은 데이터 검색 기능

-       Constraints on the data: primary key, foreign key, etc.

데이터 모델 카테고리

-       High-level(Conceptual) data models

사용자들이 이해하는 개념과 가깝게 데이터를 제공. DBMS와 독립적이며, Entity-Relationship data model, Object data model이 이에 속한다.

-       Representational(Implementation) data models

End users에게 이해하기 쉽게 개념들이 제공되지만, 컴퓨터 저장 공간에 조직된 데이터와 크게 다르지 않다. DBMS에 종속적이며, Hierarchical data model, Network data model, Relational data model이 이에 속한다.

-       Low-level(Physical) data models

데이터가 저장소에 어떻게 저장되는지 record formats, record orderings, 그리고 access paths 등에 대한 정보를 제공하는 것으로 자세하게 설명한다. 하드웨어와 독립적이며, ISAM(Indexed Sequential Method), VSAM(Virtual Storage Access Method)가 이에 속한다.

스키마, 인스턴스, 데이터베이스 상태

데이터베이스 스키마: DB에 대한 설명이다. DB가 디자인 될 때 정의되며 자주 수정되지 않는다. 대부분의 데이터 모델은 스키마를 다이어그램으로 보이기 위한 적절한 규약이 있다.

데이터베이스 상태 (Snapshot/Occurences/Instances): DB 안의 데이터의 순간적인 상태. DB 상태는 시간이 지남에 따라 자주 변할 수 있다.

데이터베이스 스키마는 intention, 상태는 extension 이라고 불리기도 한다.

Schema evolution: 어플리케이션의 필요로 하는 것이 변함에 따라 스키마에 변화가 적용되는 것.

Three-Schema 아키텍쳐와 데이터 독립성

ANSI/SPARK three-schema architecture의 목표는 물리적인 DB와 사용자 어플리케이션을 분리하는 것이다.

1.     Internal level: 내부 스키마가 데이터가 실제로 어떻게 저장되는지 설명하고, DB의 물리적 공간 설계에 대해 설명한다.

2.     Conceptual level: 개념 스키마가 DB에 어떤 데이터가 저장되는지 설명하고, DB 전체적인 구조를 설명한다.

3.     External(View) level: 외부 스키마가 부분적인 사용자 그룹이 관여하는 DB의 일부에 대해 설명한다.

매핑(Mapping): DBMS는 이 레벨들 간의 요청과 결과를 변환하는 과정을 지원해야 한다.

데이터 독립성: 어떤 레벨에서 스키마가 변경될 때, 다음 상위 레벨의 스키마가 변경되지 않음. 두 수준 간의 매핑만 변경된다.

1.     Logical data independence: 외부 스키마나 응용 프로그램을 바꿀 필요 없이 개념 스키마(Conceptual schema)를 바꿀 수 있는 능력

2.     Physical data independence: 개념 스키마(Conceptual schema)를 바꾸지 않고 내부 스키마를 바꿀 수 있는 능력

다층 레벨 DBMS에서 카탈로그는 다양한 계층에서의 요청과 데이터를 어떻게 매핑할 것인지에 대한 정보를 포함하도록 확장되어야만 한다. 일부 DBMS들은 three-schema independence가 완전히 구현되어 있는데, 계층 간의 매핑을 위한 오버헤드를 만들기 때문이다.

DB 언어와 인터페이스

Data Definition Language(DDL): 개념 스키마, 내부 스키마(SDL: Storage Definition Language), 외부 스키마 및 사용자 Views (VDL: View Definition Language)를 지정한다.

Data Manipulation Language(DML): 데이터 검색, 삽입, 삭제, 업데이트를 허용한다.

1.     Low-level or 프로시저 DML(procedural DML): 일반적인 목적의 프로그래밍 언어에 임베딩 되어야만 한다. Record-at-a-time DMLs라고도 한다. (Hierarchical model’s DL/1: GET UNIQUE, GET NEXT, GET NEXT WITHIN PARENT)

2.     High-level or 비프로시저 DML(nonprocedural DML): 복잡한 DB Operations를 간결하게 표현하는데 사용될 수 있다. 어떻게 데이터를 검색할까에 대한 것보다 어떤 데이터를 검색할지에 대한 지정을 하는 선언적 언어(declarative language)이다. Set-at-a-time 혹은 set-oriented DMLs라고도 한다.

호스트 언어, 데이터 하위 언어, 쿼리 언어

Structed Query Language(SQL): 상업적 관계형 DBMS의 표준이다. 제약 조건 지정이나 다른 기타 기능 뿐이 아니라 DDL과 DML의 조합을 나타낸다.

-       DDL: CREATE, ALTER, DROP, etc

-       DML: SELECT, INSERT, DELETE, UPDATE

-       DCL: BEGIN TRANSACTION, COMMIT, ROLLBACK, GRANT, REVOKE, etc

프로시저 언어보다는 선언적 언어인데, 이는 사용자가 프로시저를 대해 단계마다 작성할 필요 없이 선언(Declare)할 수 있다는 의미이다.

웹 기반 Menu-based 인터페이스: 옵션 리스트를 보여주어 사용자에게 요청 수식을 만들 수 있도록 유도한다.

Forms-based 인터페이스: 사용자는 모든 입력 폼에 작성해 새로운 데이터를 삽입하거나, 일부 입력 폼만 작성해 DBMS에 존재하는 데이터를 검색한다.

GUI: GUI는 스키마를 도식화해서 사용자에게 보여주는 것으로 사용자는 다이어그램을 조작하는 것으로 쿼리를 지정할 수 있다.

Natural Language Interface: 영어나 다른 자연어로 작성된 요청을 허용한다.

Interfaces for Parametric Users: 은행원과 같이 반복적인 operations를 사용해야하는 경우이다.

Interfaces for the DBA: 대부분의 DB 시스템은 DBA에게만 사용될 수 있는 권한이 있는 명령을 포함한다.

DBS 환경

DBMS 컴포넌트 모듈: DDL Compiler, Interactive query interface (Query compiler, Query optimizer), Precompiler, DML compiler, Runtime database processor, Concurrency control system, Backup and recovery system, Buffer management, Stored data manager, System catalog.

Query Processing:

1.     Parsing and Translation

2.     Optimization

3.     Evaluation

Runtime DB Processor: 컴파일 혹은 인터프리트 모드에서 쿼리 코드를 실행해 쿼리 결과를 생산한다. 이것은 카탈로그, 데이터 저장 매니저, CC/Recovery Modules와 같은 대부분의 다른 DBMS 컴포넌트와 상호작용한다.

Concurrency Control Module: 관계형 DB의 데이터 무결성을 위반하지 않게 트랜잭션들이 수행하는 것을 보장한다. 또한, 록이나 타임스탬프 같은 메커니즘들을 통해 serializability를 보장한다.

Recovery Module: 오류가 나도 DB의 지속성, 트랜잭션의 원자화(atomicity)와 내구성을 보장한다. DBMS는 DB 복구를 위해 로그나 백업을 남긴다. 일반적인 트랜잭션 처리 중에는 오류가 발생해도 복구할 수 있도록 로그로 충분한 정보를 남긴다. 만약 오류가 발생하면 redo나 undo를 취해 DB가 원자성(atomicity)와 내구성을 보장하는 상태로 복구한다.

Buffer Manager: 페이지 교체 전략(Page replacement strategy)을 구현하여 디스크 액세스를 최소화하면서, 필요한 페이지를 프로세스가 확보할 수 있도록 디스크에서 주 메모리로 페이지를 가져오는 작업을 한다.

Database System Utilities:

-       Loading: 데이터베이스에서 writing program없이 텍스트나 sequential files와 같은 존재하는 데이터 파일들을 로드하는데 사용된다.

-       Backup: DB의 백업본을 tape나 다른 mass storage에 만들어 치명적인 디스크의 오류 시에도 복구할 수 있도록 한다.

-       Database storage reorganization: 데이터 타입의 변경을 허용한다.

-       Performance monitoring: DB의 사용량과 통계를 DBA에게 제공한다.

Tools, Application Environments, and Communications Facilities:

-       CASE 도구들은 DB 시스템들의 디자인 단계에서 사용된다.

-       데이터 사전(Data dictionary, Data repository) 시스템: 디자인, 사용 표준, 응용 프로그램 설명, 그리고 주로 사용자로부터 액세스 되는 사용자 정보를 담고 있다.

-       PowerBuilder 같은 응용 프로그램 개발 환경들

-       Communication software: 사용자에게 터미널, 워크스테이션, 혹은 PC에서 DB를 제어할 수 있도록 허용해준다.

DBMS를 위한 Centralized 클라이언트 및 서버 아키텍쳐

DBS의 아키텍쳐는 DB가 운영되고 있는 컴퓨터 시스템에 의해 크게 영향을 받는다.

-       중앙화된 아키텍쳐(Centralized architecture): 모든 DBMS의 기능성, 응용 프로그램 실행, 그리고 사용자 인터페이스 처리가 하나의 중앙 컴퓨터에서 처리되어 나간다. 사용자는 원격제어 터미널이나 PC를 통해 DB에 연결한다.

-       병렬처리 아키텍쳐(Parallel architecture): DBS의 처리를 바르게 하고 트랜잭션에게 빠르게 응답하도록 한다.

-       분산 아키텍쳐(Distributed architectrure): Homogeneous, Heterogeneous): 여러 DBS의 물리적으로 혹은 논리적으로 분산 되어있는 데이터를 다룬다.

-       클라이언트-서버 아키텍쳐: 서비스 요청자인 클라이언트와 리소스나 서비스를 제공하는 서버 사이의 일을 분산하는 응용 프로그램 구조이다.

-       클라우드 아키텍쳐: 클라이언트는 클라우드를 통해 DB에 접근 가능하며, 클라우드 DB 제공자의 서버에서부터 인터넷을 통해 사용자의 요구를 전달한다. DBaaS(DB as a Service)로 불리기도 하는데, 사용자가 하드웨어와 소프트웨어 혹은 기능을 위한 설정을 할 필요 없이 DB에 접근할 수 있기 때문이다.

기본 클라이언트/서버 아키텍쳐:

-       클라이언트: 사용자의 머신으로 UI와 Local processing을 제공한다.

-       서버: 하드웨어와 소프트웨어를 포함한 시스템으로 클라이언트 머신에게 파일 액세스, 프린트, 저장, 데이터베이스 접근 서비스를 제공한다. 특수한 기능에 따라 파일 서버, 프린터 서버, 웹서버 혹은 이메일 서버 등으로 불린다.

주로 클라이언트와 서버는 서로 분리된 하드웨어에서 컴퓨터 네트워크를 통해 통신하지만, 서버와 클라이언트가 같은 시스템 안에서 상주할 수 있다.

Two-Tier Client/Server Architectures for DBMSs: 클라이언트는 UI 프로그램과 응용 프로그램을 다룬다. 서버는 SQL 처리와 관련된 쿼리와 트랜잭션 기능을 다룬다. 그리고 ODBC, JDBC 같은 API는 Client-side 응용 프로그램에서 DBMS를 호출하는 것을 허용한다.

Three-Tier and n-Tier Architectures for Web Applications: 웹 응용 프로그램들은 클라이언트와 서버 사이에 중간 층을 더한 three-tier architecture로 불리는 아키텍쳐를 사용한다. N-Tier는 저장된 데이터와 사용자 간에 더 미세한 구성 요소로 여러 층을 나눈다. 전형적으로, 비즈니스 논리 층은 여러 층으로 나뉜다. ERP의 Vendors와 CRM 패키지들은 보통 middleware를 사용한다.

DBMS의 구분

데이터 모델: Hierarchical and Network(legacy), 관계형, 객체, 객체 관계형, XML

사용자 수: Single/Multi

Site의 개수: Centralized, Distributed, Fenderated(연합) DBMS (or Multidatabase system)

가격: 오픈소스, 라이센싱

일반적 혹은 특수 목적: 특수 목적 DBMS는 항공 서비스나 전화국 시스템과 같은 성능이 주요 고려 사항인 특별한 application을 위해 만들어졌다.

데이터와 정보

데이터는 가공이 필요한 있는 그대로의 사실이다.

정보는 가공된 데이터로 그 의미를 보여준다.

DB 접근 특성

전통적인 파일 처리: 각각의 사용자를 정의하고, 파일들을 처리하는데 특별한 소프트웨어가 필요했음. 데이터의 불필요한 중복(Redundancy)이 일어나고 일관성(Inconsistency)이 없음.

DB 시스템의 자기 설명성

DBS는 구조적 정의나 제약 조건 등을 포함한다: 테이블 구조, 데이터 아이템의 타입, 데이터의 다양한 제약조건

System catalog는 Meta-data로, DB의 구조를 설명한다. DBMS 소프트웨어, DBA와 같이 DB의 구조에 대한 정보가 필요한 사용자에 의해 사용된다.

프로그램과 데이터 사이의 Insulation 및 데이터 추상화

Program-Data Independence: DB를 사용하는 어플리케이션 소프트웨어를 수정하지 않고 DB의 구조를 수정할 수 있어야 한다.

Program-Operation Independence: 객체 지향성 혹은 객체 관련성 (Object Oriented or Object Relational) DBS에서는 사용자가 데이터에 DB 정의의 일부분으로서 Operation을 정의할 수 있다.

Operation은 다음 두 가지 특성이 있다:

-       인터페이스(혹은 시그니쳐)는 인수의 Operation 이름이나 데이터 타입 등을 포함한다.

-       인터페이스에 영향을 주지 않고 구현(implementation)은 바뀔 수 있다.

프로그램 데이터에 의한 데이터 추상화 및 Program-Operation Independence: 기본적인 정보만을 외부에 제공하고 백그라운드의 자세한 정보는 숨긴다. DBMS는 사용자에게 데이터의 추상적인 묘사만을 제공하는데, 그 데이터가 어떻게 저장되어 있으며 Operation들이 어떻게 구현되어 있는지에 대해서는 보여주지 않는다.

비공식적으로, 데이터 모델은 개념적 표현을 제공하는데 주로 사용되는 데이터 추상화의 한 종류이다.

데이터의 Multiple View 지원

View: DB 파일들로부터 파생된 virtual data들을 포함하지만 명시적으로 저장되진 않는다. 데이터에 저장된 query들의 결과를 기반으로 한 Virtual table이라고 생각하면 된다. DB 사용자들은 지속성 있는 DB에 있을 때 view들을 query 할 수 있다.

Multiuser DBMS에서 사용자들은 다양한 어플리케이션들을 가지고 있다. Multiuser DBMS는 multiple view들을 정의할 수 있는 기능을 제공해야만 한다.

데이터의 공유와 Multiuser Transaction Processing

(트랜잭션: 데이터베이스에서 하나의 논리적 기능을 수행하기 위한 작업의 단위. DBS에서 복구 및 병행 시행 시 처리되는 작업의 논리적 단위. 하나의 트랜잭션은 commit 되거나 rollback 됨.)

여러 사용자를 동시에 DB에 접근할 수 있게 허용한다.

Concurrency control software(병행 처리 소프트웨어): 여러 유저들이 같은 데이터를 업데이트 하려고 할 때 통제된 방식으로 맞는 결과를 얻도록 안전하게 처리한다.

트랜잭션: Operation들의 모음으로 계좌 이체 같은 하나의 논리적 일의 단위이다. DBMS는 여러 operation들을 처리할 때 트랜잭션을 가장 작은 일의 단위로 처리하는 것으로 데이터 무결성을 유지한다.

OnLine Transaction Processing (OLTP): OLTP는 매우 빠른 쿼리를 수행한다. 많은 수의 짧은 트랜잭션을 처리하며, 많은 사용자가 동시에 접근하는 환경에서 데이터 무결성을 유지한다.

DB와 관련된 사람의 역할

DBA: 데이터베이스 스키마를 만들고 수정, 데이터베이스에 대한 접근 권한 부여, 저장소 설계 및 접근 경로 정의, DB 모니터링 및 조정, backup과 recovery 관리, 소프트웨어 및 하드웨어 리소스 취득

DB Designer: 저장될 데이터 식별, 해당 데이터를 저장하고 represent 하는데 적절한 구조 선정, views of DB

Advanced of Using the DBMS Approach

중복성 제어(Control concurrency): 같은 데이터를 중복해서 저장하는 것은 저장 공간 낭비 및 데이터 불일치 등의 문제를 야기할 수 있다. 각 논리적 데이터 아이템은 DB의 한군데만 저장되도록 DB를 조직해야한다. (데이터 일반화는 데이터 중복을 피하게 해준다.)

허용되지 않은 접근 제한, 백업과 복구 제공, 데이터 간의 복잡한 관계 표현, 효율적인 쿼리 수행을 위한 저장 공간 구조나 검색 기술을 제공, 무결성 제약 조건 강화, multiple user interfaces 제공

Rule을 활용한 추론 및 액션 허용:

-       연역적 DB 시스템(Deductive DB Systems): 저장된 DB의 사실을 이용해 새로운 정보를 얻어낼 수 있다.

-       Trigger: DB operation이 특정 조건을 위반할 때 해당 SQL statements를 자동으로 중단한다.

-       Stored Procedures: 할당된 이름이 있는 Precompile된 SQL statements로, 여러 프로그램에서 공유할 수 있다.

-       Active DB Systems: 특정 이벤트나 상태가 일어나면 자동으로 액션을 취할 수 있는 유동적인 rules을 제공한다.

Database approach를 사용해서 얻을 수 있는 추가적인 장점

-       Potential for enforcing standards

-       개발 기간 단축

-       유연성(Flexibility)

-       정보 업데이트 가능성

DB Applications의 역사

-       Hierarchical DBS: 1960s. 데이터는 하나가 다른 것들에게 연결되는 형식으로 저장됨. 1:M Relationship. 데이터 독립성과 데이터 추상화가 힘듦. 데이터 중복의 가능성.

-       Network DBS: 1970s. 데이터가 다른 것들에게 연결된 형태로 저장. M:N Relationship. Hierarchical DBS는 Network DBS의 특수한 케이스. 단점도 Hierarchichal과 비슷함.

-       Relational DBS: 1980s. 데이터 아이템들과 그 아이템들 간의 관계가 테이블로서 조직된 것. 추상적인 표현과 실제로 데이터가 저장된 곳이 다름. 데이터 추상화와 program-data 독립성이 보장됨. 사용자가 프로시저를 하나하나 조직하지 않아도 원하는 것을 얻을 수 있음(Declarative Query).

-       Object Oriented DBS: 객체지향의 특징을 적용한 데이터베이스. C++과 같은 프로그래밍 언어와 호환되며 영속 객체를 조작할 수 있음. 사용자가 정의한 Operation을 DB 객체에 사용하는 것이 허용되며 복잡한 entities를 모델화 할 수 있고, 유지와 확장이 쉽다는 장점이 있다. 하지만 모델이 복잡해지며 너무 일찍 standard가 된 것이 해가 되었다.

-       Object Relational DBS: OO 함수들을 포함한 관계형 데이터 모델을 확장함. Tuples에게 nested relations와 같이 기본적인 자료형이 아닌 타입을 가지는 것을 허용함. 일률 모델링을 확장하는 동안, 부분적으로 데이터에 대한 선언적 액세스에서, 관계의 기초를 보존함.

-       Enterprise Resource Planning (ERP): 일반적으로 비즈니스 관리 소프트웨어에서 사용함. 많은 비즈니스 활동에서 나온 데이터들을 모으고 저장하며, 관리할 수 있음.

-       Customer Relationship Management (CRM): 회사가 고객들과 판매나 서비스와 관련된 양상들을 수반함.

-       Parallel DBS: 데이터 로딩, 인덱스 제작, 그리고 쿼리 평가 같은 여러 Operations의 병렬처리를 통해 성능의 향상을 목적에 둠.

-       Distributed DBS: 인터넷이나 개인 WAN으로 연결된 컴퓨터에 데이터베이스가 분산되어 저장되어 있는 것. 트랜잭션이 한 곳 이상의 사이트에서 데이터에 대한 액세스가 일어남. DBMS는 사용자에게 세부적으로 어떻게 조직되어 있는지는 숨김.

-       Temporal DBS: 과거의 데이터를 다루는 체계적인 방법

-       Deductive DBS: DB에 저장된 rules나 facts를 기반으로 공제를 만들어낼 수 있음.

-       Active DBS: 이벤트에 따라 동작하는 아키텍쳐를 포함하며 DB 안팎에서의 상태에 대응할 수 있음.

-       Spatial DBS: 기하학 공간에 정의된 물체를 나타내는 데이터 query와 저장에 최적화 되어있다.

-       Multimedia DBS: 텍스트, 이미지, 그래픽, 애니메이션, 오디오와 비디오 같은 미디어 데이터의 집합

-       Real-time DBS: Real-time Processing을 사용하는 상태가 주기적으로 바뀌는 시스템에 사용되는 데이터베이스.

-       Cloud DBS: 클라우드 컴퓨팅 플랫폼에서 동작하는 데이터베이스로 공유된 프로세스 자원과 데이터를 사용자의 필요에 따라 제공함.

DBMS를 사용하지 말아야 할 때

DBMS의 오버헤드 비용은 다음 항목들 때문에 생긴다:

-       HW, SW, 그리고 훈련하는데 지나치게 높은 초기 환경

-       데이터의 정의와 처리 과정

-       보안, 중복 제어, 복구, 그리고 무결성 기능들을 제공하는 것

일반 파일 입출력을 사용하는 것이 더 어울릴 때:

-       단순하고 잘 정의된 데이터베이스가 성능의 향상에 영향을 거의 주지 않을 때

-       DBMS의 오버헤드 때문에 실시간으로 데이터를 요구하는 사항에는 적합하지 않음

-       저장 공간에 제약이 있는 임베디드 시스템

-       다양한 사용자가 데이터에 접근하지 않을 때