빈집 채우는 중

SQL(Structured Query Language): 상업용 relational DBMSs의 표준 언어이다. 데이터 정의, 쿼리, 그리고 수정을 위한 명령들이 포함되어 있다(DDL과 DML을 모두 가지고 있다). 핵심 서술과 추가적인 특수 확장들(공간 데이터, 시간 데이터, OLAP, 데이터 마이닝, 멀티미디어 데이터 등)로 나뉜다.

SQL 데이터 정의 및 데이터 타입

SQL 데이터 정의 언어(Data Definition Language, DDL)는 relations와 관련된 정보의 설명을 허용한다. 스키마, relations, 도메인, views, triggers, assertions의 생성, 무결성 제약 조건, 각 relation의 보안 및 권한 정보, 디스크 상에서 물리적인 저장 공간 설계, 인덱스의 집합이 유지되기 위한 정보들이 이에 해당한다.

SQL에서 스키마와 Catalog 개념

SQL 환경: 어떤 데이터가 존재할 수 있는지에 대한 프레임워크이고 데이터에 SQL operations가 실행될 수 있는지에 대한 것이다. 실제로는 SQL 환경을 곧 DBMS로 간주해야 한다. 이 환경은 clusters, catalogs, 그리고 스키마로 구성되어 있다.

Cluster: Catalogs의 모음으로, 쿼리가 영향을 미칠 수 있는 최대 범위이다. 그래서 일부 유저에게는 cluster가 곧 눈에 보이는 DB이다.

Catalog: SQL 환경에 있는 명명된 스키마의 모음이다. Catalog에 속하는 모든 스키마에 대한 정보를 포함하고 있는 INFORMATION_SCHEMA라는 특별한 스키마를 포함한다. SQL은 catalog를 생성하는 표준적인 방법을 정의하지 않는다.

SQL 스키마: 한 일부 DB 사용자 이름에 속한 DB 객체의 모음이다. DB에 있는 모든 객체들은 Sever.Catalog.Schema.Object에 있는 특별한 이름을 갖는다. DBA는 일반적으로 각 사용자에게 기본 catalog와 스키마를 지정 해주기 때문에, 사용자는 full path name을 쓰지 않고도 객체의 이름을 지정할 수 있다. 하지만 만약 사용자가 다른 스키마에 있는 객체에 접근하기 원한다면, 사용자는 명확하게 스키마의 이름을 지정한다.

CREATE/DROP SCHEMA: SQL 스키마는 스키마 이름으로 구분되고, 스키마의 각 element에 대한descriptor뿐 아니라 권한 부여 ID(Authorization identifier)를 포함한다. 아래는 여러 relations와 여러 다른 객체들을 포함한 스키마의 선언과 삭제 명령이다.

CREATE SCHEMA MovieSchema AUTHORIZATION Kim;

CREATE TABLE  MovieStar, ….

        CREATE VIEW   MovieProducer ...

        CREATE ASSERTION RichPresident, …

DROP SCHEMA MovieSchema [RESTRICT, CASCADE];

SQL의 CREATE TABLE 명령

새로운 Relation 생성: 이름, 속성, 그리고 초기 제약 조건들을 지정한다.

스키마를 선택적으로 지정해줄 수 있다:

-       CREATE TABLE EMPLOYEE ...

-       CREATE TABLE COMPANY.EMPLOYEE ... 

Base Relations: DBMS에 의해서 Relations과 그 튜플들은 실제로 생성되고 파일로써 저장된다.

Virtual Relations: CREATE VIEW 명령을 통해 생성된다.

일부 foreign keys는 참조할 테이블이 아직 생성되지 않아서 에러를 발생시킬 수 있다.

SQL에서 속성의 데이터 타입 및 도메인

속성들의 값으로 사용되는 기본 데이터 타입들이다.

DATE: YYYY-MM-DD 형식으로 년도, 월, 일로 구성되어 있다.

TIME: HH:MM:SS 형식으로 시, 분, 초로 구성되어 있다.

TIMESTAMP: DATE와 TIME 필드를 조합한 것으로, 소수점 아래 6자리까지 초 시간을 지원한다.

INTERVAL: 일정 기간을 저장하는데 사용되는 데이터 타입.

Dates와 times에 대해 비교 연산이 사용될 수 있다. 옛날 날짜가 비교적 최근 날짜보다 작은 값을 가지고, 시간도 이와 같다.

속성 제약 조건과 속성 기본값 지정

NOT NULL: 지정한 속성에 NULL은 허용되지 않는다.

기본값: DEFAULT <value>

속성 기반 CHECK 제약조건: CHECK 키워드를 통해서 더 복잡한 제약 조건이 속성이나 도메인의 선언에 덧붙여질 수 있다. 관련된 속성에 추가되는 모든 새로운 튜플에 대해 검사된다.

-       Dnumber INT NOT NULL CHECK (Dnumber > 0 AND Dnumber < 21);

-       CREATE DOMAIN D_NUM AS INTEGER CHECK (D_NUM>0 AND D_NUM<20)

Checked 속성 이외의 요소가 변경되면 복합 조건이 false가 될 수 있다.

-       presID INT CHECK (presID IN (SELECT execID FROM MovieExec)) : 만약 execID 튜플을 삭제하는 등의 경우처럼 MovieExec relation을 수정하게 되면, 위의 CHECK에서는 그 변경 사항에 대해서 알 수 없다.

Key와 무결성 제약 조건 지정

PRIMARY KEY: 하나 이상의 속성을 relation의 primary key로 지정한다. Primary key 선언은 자동적으로 속성이 not null 옵션을 갖도록 한다.

-       Dnumber INT PRIMARY KEY;

UNIQUE: Alternate(Secondary) keys를 지정한다. Unique로 지정된 속성은 null 값이 되는 것이 허용된다.

-       Dname VARCHAR(15) UNIQUE;

FOREIGN KEY: 참조하는 relation의 튜플이 삭제되거나 수정되었을 때 참조 무결성 제약 조건을 위반할 수 있다. 이 때, 기본 operation은 위반을 일으킨 update를 취소하는 것이다(SET RESTRICT). 참조된 triggered action을 덧붙이는 것으로 대체하는 행동을 지정할 수 있다. 이 옵션은 CASCADE, SET NULL, SET DEFAULT를 포함한다.

-       FOREIGN KEY (Dno) REFERENCES DEPART(Dnumber) ON DELETE SET DEFAULT ON UPDATE CASCADE;

제약 조건 명명

CONSTRAINT: 제약 조건의 이름은 나중에 제약 조건을 삭제하고 다른 제약 조건으로 대체해야 하는 경우 특정 제약 조건을 구분하는데 사용된다.

-       CREATE TABLE EMP

      ( ...

        CONSTRAINT EMPPK  PRIMARY KEY (Ssn)

        CONSTRAINT EMPSUPERFK 

            FOREIGN KEY (Super_ssn) REFERENCES EMP(Ssn) ...

CHECK를 사용해 튜플들에 제약 조건 지정

튜플 기반 CHECK 제약조건: CHECK는 CREATE TABLE 명령의 마지막에 올 수 있다. 이는 각 튜플에 개별적으로 적용되며 튜플이 삽입되거나 수정될 때 확인하게 된다. 속성 기반 CHECK 제약조건과 같은 다른 relations에서 이 조건의 존재를 확인할 수 없다.

-       CHECK (Dept_create_date <= Mgr_start_date);

SQL 기본 검색 쿼리

SELECT: DB에서 정보를 검색하는 기본 문법이다. 결과 relation의 튜플들은 원래 relation의 튜플들에 대한 부분 집합이다.

SELECT문의 기본 형태: SELECT <attribute list> FROM <table list> WHERE <condition>

-       SELECT절에는 쿼리의 결과로 보여줄 속성들을 나열한다.

-       FROM절에는 쿼리에 포함될 relations를 나열한다.

-       WHERE절에서는 결과가 만족시켜야만 하는 상태를 지정한다.

관계형 모델과 다르게, SQL은 자동적으로 중복되는 결과에 대한 처리를 해주지 않는다. 자원이 많이 드는 operation이기도 하고, 사용자가 중복되는 튜플들을 쿼리의 결과로 원할 수도 있기 때문이다.

기본 SQL 쿼리의 SELECT-FROM-WHERE 구조

FROM: Relational algebra(관계 대수학)의 Cartesian 곱 연산에 대응된다. Cartesian 곱 r1 X r2는 r1-r2의 속성으로 만들어 질 수 있는 모든 조합을 만들어낸다. Cartesian product는 그냥 사용했을 때는 그리 유용하지 않고, WHERE절과 함께 사용되었을 때 유용하다.

JOIN: 공통된 값을 사용하여 두 개 이상의 테이블의 필드를 결합하는 수단이다.

-       WHERE Dno=Dnumber AND Dname=’Research’: Dno=Dnumber는 join condition이다. 공통된 값을 이용해 두 튜플을 하나로 합치기 때문이다. Dname=’Research’는 selection condition으로 Dname이 ‘Research’인 튜플만 골라내기 때문이다.

모호한 속성 이름, Aliasing, 재명명, 그리고 튜플 변수

서로 다른 relations에서 두 개 이상의 속성이 같은 이름을 사용할 수 있다. 이럴 때 모호함을 방지하기 위해서 relation의 이름을 한정해줘야 한다. (EMP.Dnumber=DEPART.Dnumber)

Aliases 혹은 튜플 변수: 속성 이름의 모호성은 relation이 같은 relation을 참조할 때도 발생한다. Relation의 이름을 대체 선언하는 것을 Aliases 혹은 튜플 변수라고 부른다.

-       SELECT  E.Fname, S.Fname FROM   EMP AS E, EMP AS S WHERE E.Super_ssn=S.Ssn;

지정되지 않은 WHERE 절과 Asterisk 사용

WHERE 절의 부재: 튜플을 선택할 때 조건이 없음을 나타낸다. 만약 하나 이상의 relation이 FROM 절에 지정되고 WHERE절이 없으면, CROSS PRODUCT 결과 값을 내보내게 된다.

Asterisk(*) 지정: 선택된 튜플들의 모든 속성값을 검색한다.

SQL에서 집합으로서의 테이블

쿼리 결과에서 중복되는 튜플들을 제거하고 싶다면, SELECT를 사용할 때 DISTINT 키워드를 사용하면 된다.

집합 연산-UNION, INTERSET, EXCEPT(Set difference): 집합 연산자들은 자동적으로 중복되는 튜플들을 제거해준다. 이러한 집합 연산은 union-compatible(유니온 호환 관계)에만 적용된다.

-       (SELECT DISTINT Pnumber FROM PROJECT, DEPART, EMP WHERE Dnum=Dnumber AND Mgr_ssn=Ssn AND Lname=‘Smith’) UNION (SELECT DISTINT Pno FROM WORKS_ON, EMP WHERE Essn=Ssn AND Lname=‘Smith’);

Substring Pattern Matching과 산술 연산자

SQL은 문자열 비교 연산자 “LIKE”를 제공한다. ‘%’는 아무런 문자열을, ‘_’는 아무 문자와 매치된다.

-       SELECT Fname, Lname FROM EMP WHERE Address LIKE '%Houston,TX%';

표준 산술 연산자: SELECT절은 상수나 튜플의 속성에 적용될 수 있는 표준 산술 연산자를 포함할 수 있다.

-       SELECT Fname, Lname, 1.1*Salary AS Increased_sal FROM  EMP, WORKS_ON, PROJECT WHERE Ssn=Essn AND Pno=Pnumber AND Pname='X';

BETWEEN 비교 연산자:

-       SELECT * FROM EMP WHERE (Salary BETWEEN 30000 AND 40000);

쿼리 결과의 정렬

ORDER BY: SQL은 사용자가 쿼리의 결과 튜플들을 정렬하는 것을 허용한다. ASC는 오름차순 정렬, DESC는 내림차순 정렬이다. 여러 개의 속성에 대해 정렬할 수 있다.

-       SELECT name FROM instructor ORDER BY name

-       ORDER BY Salary DESC, Lname ASC

튜플 비교:

-       SELECT name, course_id FROM Instructor, Teaches WHERE (Instructor.ID, dept_name) = (Teaches.ID, ’Biology’);

SQL에서 간단한 검색 쿼리는 최대 4개의 절로 구성될 수 있는데, 첫 두 개의 절(SELECT, FROM)만 의무적으로 작성해야 한다.

-       SELECT <attribute list> FROM <table list> [WHERE <condition>] [ORDER BY <attribute list>]

SQL의 INSERT, DELETE 그리고 UPDATE문

DB를 수정하는데 사용되는 명령은 세 가지가 있다.

1.     INSERT INTO relation(attribute1, …, attributen) VALUES (val1, …, valn);

2.     DELETE FROM relation WHERE condition;

3.     UPDATE relation SET attribute=val or expression WHERE condition;

INSERT 명령

Relation의 이름을 지정하고 튜플에 들어갈 값들을 나열한다. INSERT 명령의 활용으로 쿼리의 결과로 relation에 여러 튜플들을 삽입할 수 있다.

-       INSERT INTO WORKS_ON_INFO (Emp_name, Proj_name, Hours_per_week) SELECT Lname, Pname, Hours FROM EMP, WORKS_ON, PROJ WHERE Ssn=Essn AND Pno=Pnumber ;

DELETE 명령

Relation에서 튜플들을 삭제한다. 테이블 자체를 삭제하기 위해서는 DROP TABLE 명령을 사용한다. 삭제는 DDL의 참조 무결정 제약 조건의 참조된 triggered actions에 지정되어 있을 경우 다른 relation에 있는 튜플들도 영향을 받는다.

UPDATE 명령

UPDATE 명령은 하나 이상의 선택된 튜플들의 속성 값을 수정하는데 사용된다. CASE 문을 사용할 수 있다.

-       UPDATE instructor SET salary = CASE
WHEN salary <= 100000 THEN salary * 1.05
ELSE salary * 1.03 END

SQL의 추가기능

복잡한 검색 쿼리를 지정하는 테크닉: Nested queries, aggregate functions(집계 함수: 값 집합에 대한 계산을 수행하고 단일 값을 반환함. Ex) SUM, MIN, AVG…), grouping, views, triggers, assertions(일반적인 Create 명령은 튜플이 하나도 없다면 제약 조건이 검사되지 않는데, 튜플이 존재하지 않을 때도 검사하기 위한 방법)

SQL문을 포함해 다양한 프로그램 언어에서 프로그램 작성: Embedded SQL, SQL/CLI (ODBC, JDBC), SQL/PSM, 웹 프로그래밍

Relations을 위한 파일 구조, access path, 실제 DB 설계 매개 변수를 지정하기 위한 명령 집합: Storage definition language(SDL), CREATE INDEX 명령

트랜잭션 제어 명령: 동시성 제어와 복구

사용자에게 권한 부여 및 취소 지정하기:

-       GRANT <privilege list> ON <object name> TO <user list>

-       REVOKE <privilege list> ON <object name> FROM <user list>

트리거를 만들기 위한 언어 구문

Object-Relational로 알려진 발전된 관계형 시스템: Nested relations, 사용자 지정 타입, 사용자 지정 타입에 사용되는 연산자

XML, OLAP, 데이터 웨어하우스와 같은 신기술

Relational data model: 1970년대 IBM Research의 Ted Codd가 처음 제시한 것으로, 특유의 간단함과 수학적인 기반으로 즉각적인 관심을 받았다. 모든 데이터와 그 사이의 관계를 테이블로 일관되게 구성하였다. 명확한 쿼리를 통해 데이터에 접근하며, 데이터 독립성을 제공한다. 두 개의 주된 RDBS 프로토타입들이 1970년대에 만들어졌으며, 그것들은 UCB의 Ingres developed와 IBM의 System R이다. Ingres는 MS SQL Server와 Sybase의 개발에 기여하였다. 한편, System R은 SQL/DS, DB2, 그리고 Oracle의 개발에 기여하였다.

관계형 모델 개념

관계형 모델: 데이터베이스를 관계의 모음으로 보여준다.

Relation (Table): 2차원 테이블로 기록의 모음이다.

Attribute (Column): 속성들은 테이블 열의 표제이다. 속성의 개수를 degree라고 부른다. 유효한 relation의 최소 degree는 1이다. Relation의 degree는 보통 변하지 않는다.

Tuple (Row): 속성 값의 모음이다. 실제 세상의 엔티티나 관계와 대응하는 사실을 보인다. Relation의 행 전체 개수를 cardinality라고 부른다. Cardinality는 터플이 추가되거나 제거되는 것으로 증가하거나 감소한다.

Domains, Attributes, Tuples, and Relations

Domain: 각 속성에 허용된 값의 모음이다. 프로그래밍 언어에서 데이터 타입과 비슷하다. 속성 값들은 일반적으로 atomic해서 나눌 수 없다. 특별한 값 NULL은 모든 domain의 멤버이다. 여러 속성이 같은 도메인을 갖는 것도 가능하다.

Relation 스키마 R(A)의 Relation(혹은 relation state)는 r(R)로 쓴다.

Current Relation State: 모든 가능한 조합이 주어졌을 때 relation state. 실제 세상의 특정 상태를 보여주는 유효한 튜플들만 반영함.

튜플의 구성 값: t[A_i] 혹은 t.A_i는 튜플 t의 특성 A_i값을 나타낸다.

Relations의 특징

Relation에서 튜플의 순서: Relation은 튜플들의 집합으로 정의된다. 임의로 저장 될 수 있으므로 순서는 무의미하다.

튜플에서 값의 순서: 속성과 값의 순서는 속성과 값 사이의 대응 관계만 유지된다면 중요하지 않다.

Relation의 대체 정의: 각 튜플은 (속성, 값) 쌍으로 간주될 수 있다. 각 쌍은 매핑 값을 제공한다.

튜플의 값들: 튜플의 각 값들은 atomic하다. Flat relational model은 nested relation을 허용하지 않는다. Nested relation model은 relation model의 확장으로 도메인이 atomic할수도, relation-valued 일수도 있다.

NULL 값: 속성의 값이 알려지지 않았거나 tuple에 적용되지 않았음을 보여준다. 혼란을 피하기 위해서 NULL 값은 피할 수 있는 한 피해야 한다.

Relational Model Constraints

제약 조건: 유효한 값에 대한 제한이다. DB가 보여주고 있는 실제 세상의 규칙에서 파생된다.

1.     Inherent model 기반 제약 혹은 암시적(implicit) 제약: ex) Relation은 중복된 튜플을 가질 수 없다.

2.     스키마 기반 제약 혹은 명백한 제약: 데이터 모델의 스키마로 정확하게 설명될 수 있으며, 일반적으로 DDL에서 지정한다. Ex) 도메인 제약, Key 제약, 엔티티 무결성 제약, NULL 제약, 참조 무결성 제약

3.     Application 기반 혹은 시맨틱 제약 조건 혹은 business rules: 스키마에서 직접적으로 표현될 수 없다. Trigger나 assertion같은 일부 메커니즘이나 application program에 의해서 서술되고 강요(시행)된다.

4.     Functional & Multivalued 종속성과 같은 데이터 종속성: 주로 Relational DB 설계의 장점을 테스트하고 normalization(정규화)라 불리는 프로세스에서 사용된다.

Domain Constraints

각 속성에 허용된 값들의 집합이다. 각 튜플의 각 속성 A의 값은 도메인으로부터 atomic value여야만 한다. 데이터 타입은 도메인에 연관되어 값의 타입을 제한한다. Integer, real number와 같은 숫자형 타입과 character, Boolean, 고정/가변 길이 문자열, 날짜, 시간, 타임스탬프, 금액, 그리고 여러 특수한 데이터 타입이 있다. 속성의 기본 값, 유효값 범위, 혹은 ‘NOT NULL’ 옵션 등을 정할 수 있다. SQL2는 명확하게 도메인을 정의하는 것을 허용한다. (CREATE DOMAIN DeptNameType AS CHAR(10) DEFAULT ‘Sales’;) 도메인은 이름, 데이터 타입, 심지어는 형식까지 주어진다.

Key Constraints

Relation은 튜플들의 집합으로 정의되기 때문에, relation에 속한 각 튜플들을 구분하는 방법을 가지고 있어야만 한다. 만약 K의 값이 가능한 relation r(R)의 각 튜플들에 대해 구분하기에 충분하면, ’K Í R & K’를 R의 superkey라고 하자. Superkey K는 K가 더 이상 축소시킬 수 없을 경우 key이다. 즉, K로부터 어떠한 속성 A를 제거하는 순간 R에 대한 superkey가 아니게 된다. 만약 relation 스키마가 1개 이상의 key를 가지고 있을 경우, 각각을 ‘Candidate key’라고 부른다. Candidate key 중 하나가 primary key가 되며, 다른 candidate keys는 secondary keys(alternate keys)로 불리며, 고유 키로 지정된다.

RDBs and Relational Database Schemas

Invalid state: DB의 상태가 모든 무결성 제약 조건을 따르지 않았을 때

Valid state: DB의 상태가 무결성 제약 조건 집합에 속한 모든 제약 조건들을 만족시킬 때

무결성 제약 조건들은 DB 스키마에 지정되어 있으며, 그 스키마의 모든 유효한 DB 상태를 유지할 것으로 예상되도록 한다.

Entity Integrity, Referential Integrity, Foreign Keys

엔티티 무결성 제약 조건: Primary key의 값은 NULL이 될 수 없다. Relation에 속한 각 튜플들을 구분하기 위해서 primary key의 값을 사용하기 때문이다.

참조 무결성 제약 조건: 두 relations간에 지정되며 두 relations 사이에 있는 튜플들의 일관성을 유지하기 위해서 사용된다. 비공식적으로, 다른 relation을 참조하는 한 relation의 튜플은, 그 다른 relation에 존재하는 튜플을 참조해야 한다.

Foreign key: 한 relation에 있는 속성으로 다른 relation의 튜플을 구분할 수 있도록 해준다. Foreign key의 속성은 이것을 참조하는 relation의 primary key 속성과 같은 도메인을 가진다. 또한, r₁(R₁)의 튜플 t1에서의 Foreign Key 값은 r₂(R₂)의 일부 튜플 t2에 대해 Primay key의 값이 되거나 NULL 값이다.

Foreign key는 자신의 관계를 참조할 수 있다.

다른 타입의 제약 조건들

Application 기반 혹은 시맨틱 무결성 제약 조건: Relational DB에서 지정되고 지켜져야 한다. Triggers와 assertions라 불리는 메커니즘이 사용될 수 있다. Application programs에서 이러한 유형의 제약 조건들을 검사하는 것도 가능하다.

Functional dependency constraint: 속성 X와 Y로 이루어진 집합 사이에 functional relationship을 세운다. 이 제약 조건은 X의 값이 고유한 Y값을 결정하도록 지정한다(X → Y). 품질을 향상하기 위해서 relations을 정규화(normalize)하는데 functional dependencies와 다른 타입의 의존성을 도구로써 사용한다.

*) Normalize: RDBS에서 중복을 최소화하게 데이터를 구조화하는 프로세스

*) Functional dependency: Relation에서 두 개의 속성 집합 간 제약의 일종.

State(Static) constraints: DB가 만족시켜야만 하는 적절한 state를 결정하는 제약 조건을 정의한다. 함수와 같이 어떠한 값을 통해 종속 관계에 있는 다른 값을 유일하게 결정할 수 있다는 것이다.

Transition(Dynamic) constraints: DB에서 state가 변경되는 것에 대응하기 위해 정의한다.

Update Operatinos, Transactions, and Dealing with Constraint Violations

Relational model의 operations는 검색과 수정으로 분류할 수 있다.

Insert, Delete, Update는 DB의 relations의 상태를 변경하는 기본적인 operations들이다. 이 operations가 적용될 때마다, 관계형 DB 스키마에 지정된 무결성 제약 조건을 위반해서는 안된다.

Delete Operation: 삭제된 튜플이 다른 튜플들에게 foreign key로써 영향을 주면 참조 무결성 제약 조건만을 위반할 수 있다.

Insert Operation: 네 가지 제약 조건 모두를 위반할 수 있다.

Update Operation: 대체로 수정되는 속성이 primary key 혹은 foreign key가 아닐 경우에는 문제를 일으키지 않는다. DBMS는 새로운 값이 알맞은 데이터 타입 그리고 도메인인지만 확인하면 된다. 하지만 Primary/foreign key를 수정하는 경우에는 Insert/Delete와 비슷한 문제가 발생할 수 있다.

참조 무결성 제약 조건 위반을 다루기 위한 4가지 옵션이 있다.

-       Restrict option: 기본 값으로, 명령을 거부한다.

-       Cascade option: 삭제하려는 튜플을 참조하는 모든 튜플들을 삭제한다.

-       Set Null 혹은 Set default option: 위반을 유발하는 참조하는 속성 값을 null이나 default 값으로 수정한다.

CREATE TABLE EMPLOYEE ( 

        EMPNO      INTEGER  NOT NULL,

        DNO          INTEGER,

        PRIMARY KEY (EMPNO),

        FOREIGN KEY (DNO) REFERENCES DEPARTMENT (DEPTNO)

               ON DELETE SET NULL; ON UPDATE CASCADE  );

트랜잭션 개념

트랜잭션: 하나의 논리적 일의 단위를 이루는 operations의 모음. 트랜잭션은 데이터 무결성을 보존하기 위해서 ACID 속성을 소유해야한다.

-       Atomicity: 트랜잭션의 모든 operations는 DB 내부를 적절히 반영되거나 없어야 한다.

-       Consistency: 트랜잭션의 실행은 DB의 일관성을 보존해야한다.

-       Isolation: 각 트랜잭션은 다른 트랜잭션과 독립적으로 실행되어야 한다.

-       Durability: 트랜잭션이 성공적으로 실행되고 나서는, 시스템에 장애가 있더라도 DB에 대한 변경사항은 지속되어야 한다.

대부분의 DBS는 각 SQL문을 하나의 논리적인 일의 단위로 간주한다.

BEGIN TRANSACTION, COMMIT, 그리고 ROLLBACK(혹은 이와 동등한) 키워드들은 트랜잭션을 구분하기 위해서 DML에서 사용 가능하다.

BEGIN TRAN
     INSERT publishers VALUES (1111, ‘PEARSON’, ‘Seoul’, ‘’, ‘South Korea’)
     UPDATE publishers SET pub_name = ‘Old Book’ WHERE pub_id = ‘0736’

          IF @@ERROR = 0  COMMIT TRAN
          ELSE                   ROLLBACK TRAN

END TRAN

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

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의 오버헤드 때문에 실시간으로 데이터를 요구하는 사항에는 적합하지 않음

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

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