4.1 SQL의 데이터 정의와 데이터 타입

4.1.1
SQL 환경 : SQL을 사용할 수 있는 어떠한 프레임워크를 설치한 것
클러스터 : catalog의 집합
catalog : 어떤 SQL 환경에 있는 스키마들의 모임
SQL schema : schema의 이름으로 식별, schema의 각 원소(테이블, 제약조건, 뷰, 도메인 등)에 대한 기술자 뿐 아니라 소유계정을 가리키는 권한부여 식별자도 포함

4.1.2 SQL의 CREATETABLE 명령
relation의 이름과 함께 attribute의 초기 제약조건들으 명시하여 새로운 relation을 만드는데 사용
각 attribute마다 이름, 값의 도메인을 명시하는 데이터 타입, NOT NULL과 같은 제약조건을 포함 그 외의 제약조건은 attribute들이 선언된 후 CREATE TABLE 구문 안에서 표현되거나 나중에 ALTER TABLE로 표현됨
base relation : CREATE TABLE로 정의된 relation
virtual relation : CREATE VIEW로 정의된 것
외래키들이 순환 참조하도록 선언하거나 아직 생성되지 않은 테이블을참조하면 외래키에 오류가 발생

4.1.3 SQL에서 attribute data type & domain
DATE data type : YYYY-MM-DD
TIME data type : HH:MM:SS
TIMESTAMP data type : YYYY-MM-DD HH:MMM:SS.SSSSSS
INTERVAL data type : 세기의 시간을 저장

4.2 SQL에서 기본 제약조건 명시

4.2.1 attribute 제약조건과 default값 명시 : SQL은 attribute값으로 NULL을 허용하기에 아니면 NOT NULL씀
또한 DEFAULT <value> 를 이용하여 default value를 명시할 수 있다.

4.2.2 키와 참조 무결성 제약조건의 명시
CREATE TABLE 구문에 키와 참조 무결성을 위한 특별한 절을 가진다.
UNIQUE 절은 대체키를 명시한다.
FOREIGN KEY절은 참조무결성을 명시(tuple들을 삽입, 삭제, 수정할때 위배할 수 있다.)

4.2.3 CONSTRAINT 다음에 제약조건의 이름을 부여
4.2.4 CHECK를 사용하여 테이블제약조건을 명시 (CREATE TABLE의 끝에 사용)

4.3 SQL에서의 기본 검색 질의(SELECT FROM WHERE)
SQL과 관계모델의 차이점으로는 SQL table은 tuple들의 집합이 아니고 tuple들의 다중집합이다.
SELECT에 DINTINCT를 함께 사용하면 SQL relation에 집합의 성질을 갖도록 함

SELECT <attribute list> ,FROM <table list>, WHERE<조건>
JOIN : 두개 이상의 table을 합치는데 사용

4.3.2 모호한 attribute 이름,별명, 재명명, 투플 변수

Relation name.attribute name, AS를 사용하여 재명명, 별명을 만들수도 있다.
4.3.3 where절을 생략하면 Relation의 모든tuple검색되고 만약 FROM에 두개 이상의 relation이 명시되고, where절이 없다면 크로스프로덕트(모든 가능한 tuple의 조합)이 검색된다.
선택된 tuple들의 모든 atrribute값을 검색하려면 SELECT절에 attribute명 대신 *을 입력한다.

4.3.4 SQL에서 집합으로의 테이블 : 앞에서 말했듯이, SQL은 집합보다는 다중집합으로 table을 표현한다. 중복 tuple이 테이블의 질의의 결과에서 하나 이상 나타날 수 있다. => SQL은 중복 tuple을 제거하지 않는다.
키를 가진 SQL 테이블은 키값이 각 tuple마다 구별되어야 하므로, 집합으로 표현되도록 제한을 받는다. SQL 결과에서 중복된 tuple을 삭제하려면 SELECT절에 키워드 DISTINCT를 사용한다.
SQL에서의 관계 대수 : 합집합(UNION), 차집합(EXCEPT), 교집합(INTERSECT)가 있다.
관계대수 다음에 ALL을 붙이면 중복을 허용한다. Ex) UNION ALL

4.3.5 부분 문자열 패턴 비교와 산술 연산자
LIKE를 통해 문자열의 일부에 대해서 비교 조건을 명시한다 (몇글자, 시작하는 문자)
질의 내에서 산술식을 허용한다(사칙연산), BETWEEN을 사용하여 범위를 지정한다.

4.3.6 질의 결과의 정렬
ORDER BY를 사용하여 질의결과에 있는 tuple들을 정렬(default는 오름차순, DESC를 사용하면 내림차순)

4.4 SQL에서 삽입, 삭제, 갱신문

4.4.1 INSERT 명령 : 한 relation에 tuple을 추가
relation 이름과 attribute값들의 리스트를 명시해야 하며 attribute들의 순서는 CREATE TABLE에서 명시한 attribute들의 순서와 일치해야한다.
새로운 tuple에 일부 attribute만 명시할 경우에는 INSERT INTO R (attributes)를 사용하고 다음줄에 VALUES (삽입할 attribute)를 사용한다.

4.4.2 DELETE 명령 : 한 relation에서 tuple을 삭제한다. WHERE절과 같이 사용할 수 있다. 한번에 한 테이블 내의 tuple들만 삭제할 수 있다. 그러나 DDL에서 참조 무결성 제약조건 내에 참조 트리거된 동작이 명시되어있다면 삭제는 다른 relation에 있는 tuple들도 연쇄적으로 삭제할 수 있다. table자체를 삭제하려면 DROP TABLE

4.4.3 UPDATE 명령 : 선택된 하나 이상의 tuple에서 attribute값들을 수정하기 위해 사용
DELETE 명령처럼 UPDATE명령에 있는 WHERE절은 한 relation에서 수정할 tuple들을 선택

JOIN

기본형식

SELECT ‘열 목록’ FROM ‘테이블1’ ~join ‘테이블2’ ON (join 조건)

의미

각 테이블 간 의미 있는 데이터를 연결하는데 사용하는 메커니즘이며 적어도 하나의 컬럼이 테이블 사이에서 공유되어야 한다.

필요한 이유

RDB를 정규화 하면 데이터 집합으로 테이블이 구성되고, 각 테이블끼리는 관계를 갖는다.

이러한 특징으로 RDB는 저장공간의 효율성과 확장성이 향상된다.

한편, 서로 관계 있는 데이터가 여러 테이블로 나뉘어 저장되므로, 각 테이블에 있는 데이터를 효율적으로 검색하기 위해 조인이 필요하다.

표현 방식

명시적 표현법과 묵시적 표현법이 있으며, 

명시적 표현법은 ‘SELECT column FROM A_table JOIN B_table ON (A_column = B_column)’이고, 

묵시적 표현법은 ‘SELECT column FROM A_table, B_table WHERE (A_column = B_column)’와 같이 사용한다.

INNER JOIN과 OUTER JOIN이 있는데, 이 둘의 차이점은 INNER JOIN은 조인조건에 만족하지 않는 데이터를 출력한다면 OUTER JOIN, 그렇지 않다면 INNER JOIN이 된다.

1.     INNER JOIN : 가장 일반적인 조인 형태로 빈번하게 사용한다. 둘 이상의 테이블에 존재하는 공통 컬럼의 값이 같은 것을 결과로 추출한다. 내부 조인에는 ‘동등 조인’, ‘자연 조인’, ‘교차 조인’ 등이 있다.

A.     동등 조인 : ‘Equi join’이라고도 하며, 조인의 가장 일반적인 형식이다. 둘 이상의 테이블에 존재하는 공통 컬럼의 동등만을 비교하며, 부등호 조인은 동등 조인에 포함 되지 않는다.

B.      자연 조인 : ‘natural join’이라고도 하며, 조인 대상 테이블의 모든 컬럼을 비교하여 같은 컬럼명을 가진 컬럼으로 조인을 수행한다. 이때, 동일한 이름은 갖는 컬럼은 한 번만 추출한다.

C.      교차 조인 : ‘cross join’이라고도 하며, 조인에 들어간 테이블들의 모든 데이터가 추출된다. 조인 조건이 잘못되었거나 정의하지 않았을 때, 테이블의 모든 행이 조인되는 경우에 발생한다. Cartesian Product 값을 얻을 수 있다. 너무 많은 레코드를 생성할 위험이 있기 때문에 드물게 사용하며, 테스트 용도로 대용량의 테이블을 생성시에 사용한다.

D.     셀프 조인 : 자가 조인이라고도 하며, 하나의 컬럼에 있는 값들과 이 컬럼에 들어있는 다른 값을 비교할 때 사용한다. FROM절에 각각 다른 alias를 지정하여 테이블을 대입한다. 테이블의 한 컬럼이 자신의 다른 레코드를 참조할 때 사용한다.

2.     OUTER JOIN : 특정 테이블의 데이터가 모두 필요할 때 사용한다.

A.     LEFT OUTER JOIN : 오른쪽 테이블에 조인할 컬럼의 값이 없는 경우 사용한다. 왼쪽 테이블의 모든 데이터를 포함하는 결과를 만든다.

B.      RIGHT OUTER JOIN : 왼쪽 테이블에 조인할 컬럼의 값이 없는 경우 사용한다. 오른쪽 테이블의 모든 데이터를 포함하는 결과를 만든다.

C.      FULL OUTER JOIN : LEFT OUTER JOIN과 RIGHT OUTER JOIN을 합친 것으로 양쪽 모두 조건이 일치하지 않는 것들까지 모두 결합하여 출력한다.

Observer pattern

정의

한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들이 자동으로 갱신되는 방식으로 객체들 간에 one-to-many 의존성을 정의한다. 객체의 상태 변화를 관찰하는 Observer들을 객체에 등록하여 상태 변화가 있을 경우 객체가 메소드를 통해 Observer들에게 알리는 Design pattern이다. 주로 분산 이벤트 핸들링을 구현하는데 사용하거나, 하나의 객체에 여러 개가 의존할 경우 사용하는 것이 대부분이다.

l  자바에는 java.util.Observable이라는 API가 있다. 하지만 interface가 아니라 class이기에 이미 다른 super class를 extends하고 있는 class에서는 사용할 수 없다는 점과, 직접 구현이 불가능하다는 단점이 존재한다. 그리고, 핵심 method(‘setChange()’)는 protected로 선언이 되어있기때문에 해당 method를 외부에서 사용하는 것이 불가능하다 라는 단점이 있다.

조건

Loose-Coupling : 필요한 이유는 객체 간의 결합도가 높아질수록 유지보수는 힘들기 때문이다.  Loose-Coupling의 특징으로는 주체가 observer에 대해서 observer interface를 implement하고 있다는 점을 제외하고는 알 수 있는 정보가 없다. Loose-Coupling의 장점은 Observer를 언제든지 추가할 수 있고, 새로운 Observer라 해도 주체를 변경할 필요가 없으며 주체와 observer를 독립적으로 사용할 수 있다. 또한 Observer가 바뀌어도 서로 영향을 미치지 않는다는 것이다.

구성

 2개의 역할을 하는 interface(subject, observer)를 생성한다. subject라는 interface는 observer들을 관리하는 method들을 가진다. 이 method들은 observer를 add, delete, notifyObserver 이렇게 3가지 역할을 한다. Observer interface는 정보를 업데이트 해주는 update method를 가진다. Subject를 implment한 class는 정보를 제공하는 subject가 되며 observer 객체들을 가진다. 그리고 observer interface를 implement한 class는 notifyObserver method를 호출하면서 알려줄 때마다 update method가 호출된다.

정리

1.    Observer pattern은 한 object의 state가 바뀌면 해당 object에 의존하는 다른 object들에게 신호를 보내고 자동으로 정보가 갱신되는 1:N의 관계를 가진다.

2.    연결은 interface를 이용하여 loose-coupling을 유지한다.

3.    Observer pattern은 push 방식(주체 object에서 observer로 데이터를 보내는 방식)과 pull 방식(observer에서 주체 object의 데이터를 가져가는 방식)으로 언제든지 구현할 수 있다.

4.    JAVA에서는 Observable class와 Observer interface를 제공한다.

구현 (팬관리)

Strategy Pattern

정의

어떤 동작을 하는 알고리즘을 정의하고 각각을 Encapsulation하고 Delegate를 통해서 어떤 행동을 할지 결정하는 패턴이다. Strategy pattern을 이용하면 알고리즘을 사용하는 client는 독립적으로 알고리즘을 변경할 수 있다. 상속보다는 구성을 이용한다. 즉 ‘A는 B다’ 보다는 ‘A에 B가 있다’라는 패턴이다. 정리하자면, 하나의 결과를 만드는 목적은 동일하나, 그 목적을 달성할 수 있는 방법이 여러가지 존재할 경우 기본이 되는 template method와 함께 많이 사용되는 패턴이다.

사용하기 좋은 경우

1.    행동만 조금씩 다를 뿐 관련된 class가 많을 때

2.    알고리즘의 변형이 필요할 때

3.    User가 몰라야 하는 data를 사용하는 알고리즘이 있을 때

4.    하나의 class가 많은 행동을 정의하고, 이런 행동들이 그 class의 연산 안에서 복잡한 조건문의 형태일 때

구성

1.    여러 개의 sort algorithm을 정의하고 필요에 따라 선택적으로 적용한다.

2.    App에서 달라지는 부분을 찾아내어, 그렇지 않은 부분으로부터 분리한다.

3.    구현이 아닌 interface에 맞춘다.

4.    inheritance보단 composition을 활용한다.

장점

1.    알고리즘을 Encapsulation 시켰기 때문에 확장성이 좋다.

2.    프로그램이 실행 중에 알고리즘을 setting할 수 있다.

3.    로직을 독립적으로 관리하기 쉽다는 장점이 있다.

4.    코드의 중복을 줄일 수 있다.

단점

Strategy Object와 Context Object 사이 의사소통에 overhead가 있다.

    UML

Design Pattern

정의 

방식을 통해 SW 설계에서 얻은 세세한 경험들을 기록해 놓도록 하는 것으로 특정한 상황에서 구조적인 문제에 대한 해법이라 할 수 있다. 그 중에서도 anti-pattern이라는 것이 있는데, 이는 실제로 많이 쓰는 pattern이지만, 비효율적이고, 비생산적인 pattern을 뜻한다. 일반적으로 하나의 패턴에는 다음 4가지 요소가 들어가 있다.

1.    Pattern name은 한두 단어로 설계 문제와 해법을 서술한다.

A.     패턴의 이름을 정의해 두면 문서에서 이 이름을 사용하여 설계의 의도를 표현하기가 편리하다. 또한, 설계에 대한 생각이 쉽고, 개발자들 간의 communication이 원활해 진다.

2.    문제는 언제 패턴을 사용하는가를 서술하며 해결할 문제와 그 background를 설명한다

A.     ‘어떤 알고리즘을 이용하여 객체를 생성할까’와 같은 설계의 세세한 문제를 설명할 수 있다.

3.    Solution은 설계를 구성하는 요소와 그 요소들 사이의 관계들의 책임, 협력 관계를 서술한다.

A.     어떤 구체적인 설계와 구현을 설명하는 것은 아니다. 그 이유는 pattern은 다양한 경우에 적용할 수 있는 template이기 때문이다. Design pattern은 구체적인 부분이 아닌 추상적인 설명을 주고 해결하기 위한 클래스와 객체들의 열거 방법을 제시한다.

4.    결과는 design pattern을 통해 얻을 수 있는 결과와 장점, 그리고 단점을 서술한다.

A.     설계를 결정할 때에는 설계의 결과를 고려하여야 한다. 여기서 결과는 시공간의 효율을 중요한 요소로 볼 것인지에 따라서 다른 설계 방법을 택해야 한다. Reuse는 OOP설계의 주요소이기 때문에 pattern의 결과는 system의 유연성, 이식성, 확장성 등에 큰 영향을 끼친다.

디자인 패턴이 필요한 이유

1.    코드가 명확하고 가독성이 좋아진다.

2.    모듈(class, function, etc.)은 한가지 기능만 하도록 세분화 된다.

3.    재사용성이 높아진다.

4.    유지보수가 쉬워진다.

5.    리소스의 낭비가 적어진다.