키워드: 파일DB와 DBMS의 차이, 무결성, DB설계 단계, Data 독립성, 동시성제어(트랜잭션, Locking, 데이터 추상화, 데이터 모델(저수준, 고수준), 데이터 독립성, 3단계 스키마, ER다이어그램)
1. 데이터베이스
- 특정한 의미를 갖는 연관 있는 자료들의 모임
2. Database Management System(DBMS)
- 데이터베이스를 정의, 생성, 조작, 공유할 수 있도록 편리한 기능을 제공하는 소프트웨어 시스템
- 데이터베이스 정의: DB에 저장하는 데이터의 타입, 구조, 제약조건을 명세하는 것. 이 정보는 카탈로그나 사전의 형태로 저장되고 이를 메타데이터라고 부름.
- 데이터베이스 조작: 쿼리문을 통해 데이터를 검색하고 갱신하는 젓.
3. 파일DB와 DBMS를 이용한 DB의 차이
- 데이터 관리할 때, 파일 DB의 경우 사용자가 파일의 물리적인 구조를 알아야하며, 데이터의 중복이 발생할 수 있고, 무결성 원칙을 지키기 힘듦.
- DBMS를 이용한 DB의 경우, 데이터 중복(redundancy)이 감소하고, 데이터 저장시 일관된 표준 체계를 적용할 수 있음.
- 파일DB에서 논리란 A 파일에 B, C 데이터가 몇바이트부터 몇바이트에 있다는 것이지만, DBMS를 이용한 DB에서의 논리는 B 데이터는 어떤 의미의 데이터이고, C 는 어떤 의미인데, B와 C는 어떤 관계성이 있다는 것을 의미함.
- 파일DB(SQL lite) 는 로컬상에서 적은 규모의 프로그램을 위해 사용되고, 자료 저장 및 출력하는 기능만 수행 함. (네트워크를 통한 자료공유나 백업 복구 같은 기능이 없음.)
- DBMS의 DB 사용 시, 데이터에 대한 다중 뷰, 데이터 공유 및 트랜잭션 처리가 용이.
- 파일DB는 파일 구조가 변하면 프로그램에서의 파일 DB 접근 방식이 바뀌어야 함.
- 파일DB는 redundancy(중복) 된 수 만큼 반복해서 변경사항을 적용하지 않으면 inconsistency가 발생하여 문제가 될 수 있음.
- DBMS의 DB는 사용자에 대한 권한을 부여 가능하여 특정 사용자에게만 데이터를 보여줄 수 있으며,
Data Integrity(무결성)을 지원하여, 데이터 변경이나 수정, 삭제시 정확성을 유지하게 함.
- Data Integrity(저장된 데이터의 일관성, 정확성을 의미): 도메인 무결성, 개체 무결성, 참조 무결성
- 도메인 무결성: 컬럼에 대한 무결성으로 널(null)을 허용하거나, 적정한 형식의 데이터가 저장되었는지를 확인, Check, Default, Rule등의 제약으로 지원 함.
즉, 자료형, 규칙과 제약, 값 범위등을 제한하는 것. 또한 도메인 집합 안에서 존재할 수 있는 값만 갖는다.
- 개체 무결성: 다른 행들의 값과 중복되지 않는 것을 보장. 즉, 테이블에 있는 모든 행들이 유일한 식별자를 갖게 함.
primary key, unique 같은 constraint로 지원. primary key의 경우 NULL도 될 수 없음.
- 참조 무결성: 개체와 개체간에 참조관계일 때, 두 개체간에 데이터가 일관성을 갖게 함.
Foreign key 또는 Trigger로 지원하며, 데이터 변경시 관련 값들을 조정할 수 있게 함.
외래키(FK, foreign key)의 경우 참조하려는 테이블의 PK를 정확히 가지고 있던지 아니면 NULL을 가져야 한다.
4. 데이터베이스 설계 단계
- 요구사항 정의 및 분석: 문서화
- 개념적 설계(Conceptual design): ER 모델사용
- 논리적 설계(Logical design): DBMS에서 구현되는 데이터 모델로 표현
- 물리적 설계(Physical design): DB에 데이터를 저장하고 접근하는데 필요한 상세(specifications)를 제공
5. DBMS Catalog(카탈로그, 메타데이터)
- DB에 속하는 각 파일들의 구조, 데이터 항목의 타입, 저장형식, 데이터의 제약조건들이 카탈로그에 저장되며, 카탈로그에 저장된 정보들을 메타데이터라고 부른다.
이 정보가 데이터베이스의 구조를 기술한다.
- DB의 Table 만들 때, Create table XXX(~~~);에서 ‘~~~’ 정보들을 카탈로그라고 함.
6. DBMS를 이용한 DB 사용 시, 사용자 Program과 Data의 분리(독립성)성
- 데이터 저장하는 구조가 바뀌어도 이를 사용하는 응용프로그램은 변하지 않으며, 이것이 program-data independence 이다.
- 예: 웹에서 DB 설계하고, 나중에 attribute 하나 추가되었다고 웹이 바뀌는 것이 아니다.
- data abstraction: 이러한 독립성으로 인해 데이터 구조(몇바이트부터 몇바이트까지 어떤 데이터가 있는지)를 제공하는 것이 아닌
데이터에 대한 개념적 표현을 제공하게 된다.
7. DBMS 내부의 동시성제어(concurrency control) 프로그램
- 갱신 내용, 모순, 연쇄적인 롤백 등을 위해 필요함.
- 트랜잭션 처리를 위해 데이터의 일관성(consistency), 각 트랜잭션끼리의 고립(Isolation)(서로 독립되어, 분리되어 실행된다는 것), 원자성(Atomicity),
지속성(Durable)(한번 트랜잭션이 성공하면 지속적으로 유지되어야 한다는 것)을 지원.
- 트랜잭션을 스케쥴하고 직렬성을 제공.
- 동시성 제어기법
① Locking: 트랜잭션이 사용하는 자원, 데이터 항목 등에 대해 상호배제 기능을 부여하는 것.
한 트랜잭션이 데이터 항목에 대해 잠금(lock)을 설정하면 잠금을 설정한 트랜잭션이 잠금을 해제(unlock)할 때까지 데이터 항목을 독점적으로 사용할 수 있음.
기본 개념: 데이터 접근시 lock()을 하고 수행 후, unlock()을 함. 세마포어랑 같음.
Locking 연산: Shared-lock(A 트랜잭션에 의해 락이 설정되면, B는 쓰지는 못하지만 읽기는 가능), Exclusive-lock(A가 락을 설정하면 B는 읽지도 쓰지도 못함)
Locking 단위: 단위의 크기에 따라 데이터베이스-릴레이션(파일)-튜플-속성 으로 구분.
단위가 크면 구현이 쉽지만 동시성이 떨어지고, 단위가 작으면 구현이 어렵지만 동시성이 커짐.
② Time Stamp Ordering: 시스템에서 생성하는 고유 시간 스탬프를 트랜잭션에 부여.
- Two Phase Locking Protocol(2단계 락킹): 확장단계(트랜잭션은 lock만 수행하고 unlock은 불가능), 축소단계(unlock만 가능하고, lock은 불가능)를 통한 locking.
8. 데이터 추상화(data abstraction)를 통해 원하는 부분만 볼수 있음.
- 데이터 모델: 데이터베이스의 구조를 명시하여 추상화에 필요한 수단 제공, 검색과 갱신을 수행하는 연산들 포함.
- 데이터베이스 구조: 데이터 타입, 관계, 제약조건들.
9. 데이터 모델
- 저수준 또는 물리적 데이터 모델: 데이터가 어떻게 컴퓨터에 저장되는가를 명시, 레코드 형식, 접근 경로 같은 것.
- 고수준 또는 개념적 데이터 모델: 사람들이 데이터를 인식하는 방식에 대한 개념. Entity, Attribute, relationship 개념을 사용.
Entity는 사원이나, 프로젝트 같은 실세계의 개념이고,
Attribute는 사원의 이름이나 급여 같은 Entity의 특성,
Relationship은 사원과 프로젝트 사이의 관계처럼 두 개 이상의 Entity 사이의 연관성을 의미.
10. DB Schema(내포, intension): DB에 대한 기술, 하나의 Entity에 대한 Attribute를 정의
- 예: Student: Name, Student_Number, Major
- Schema와 제약조건을 메타데이터라고 부르며, DBMS 카탈로그에 저장함.
11. DB snapshot(occurence, instance, 현재 상태, 외연, extension)
- 특정 시점에서 DB에 있는 데이터.
12. 3단계 Schema 아키텍처: 물리적 DB와 사용자의 응용프로그램을 분리
- 내부 단계(internal level, internal schema(내부 스키마)): 데이터베이스의 물리적 저장구조 기술, DB 접근 경로 같은 것 기술
- 개념 단계(Conceptual level, conceptual schema(개념스키마)): 모든 사용자들을 위한 전체 DB 구조 기술, 즉, Entity, relationship, data type, constraint 기술.
- 외부 단계(external level, view level(뷰 단계)): 사용자가 관심있어 하는 부분만 보임
- 최종 사용자 ⇔ 개념스키마 ⇔ 내부스키마 ⇔ 저장된 DB
13. 데이터 독립성을 위해 3단계 Schema 아키텍처를 사용함.
- 논리적 데이터 독립성: 외부 스키마나 응용프로그램을 변경하지 않으면서 개념 스키마를 변경하는 것.
DB 확장, 제약조건 갱신을 하여 개념 스키마를 변경할 때, 외부스키마가 영향을 받아서는 안됨.
- 물리적 데이터 독립성: 개념스키마를 변경하지 않으면서 내부 스키마를 변경할 수 있는 것.
또한 외부 스키마 역시 변경할 필요가 없음.
예: 레코드 검색 성능 높이기 위해 알고리즘을 바꾸는데 개념 스키마나 외부 스키마가 변경될 필요는 없다.
14. DBMS 사용시 tier
- 2tier: DBMS 연결시 ODBC 같은 API로 통신
- 3tier: 웹서버 같이 Client가 요청하면 웹서버로 요청이 가고, 웹서버에서 허가받지 않은 사용자를 걸러내기도하며, 이 요청을 DBMS로 다시 보냄.
15. Entity-Relationship 모델 (ER 모델): 고수준의 개념적 데이터 모델
16. ER 다이어 그램
- key attribute는 타원 내에서 이름에 밑줄을 그어 표시한다.
key는 unique와 minimal 속성을 갖는다.
복합키(composit key)의 경우 여러개의 attribute에 밑줄을 긋는다.
- 엔티티 타입이 key를 갖지 않는 경우 weak entity type 이라고 한다.
- 다치(multivalued) attribute: 자동차 색깔 같이 여러개의 값을 갖을 수 있는 것. 두 줄로 된 타원으로 그림. 중괄호로 표시
- 복합(complex) attribute: 이름, 주소 같은 것.
- 한 Entity type이 다른 Entity type을 참조할 때, 두 Entity 사이에서는 Relationship이 성립되며, ER 모델에서는 이런 참조들을 attribute로 표현하지 않고,
관계로 명시해야 한다.
- relationship type은 ER 모델에서 다이아몬드 모양으로 나타내며, 관계에 참여하는 Entity들은 직선으로 연결되고, 관계이름이 다이아몬드 모양 안에 나타난다.
- 관계차수: 관계에 참여하는 Entity type의 개수, 2개면 binary, 3개면 ternary(삼진)
- 참여 제약: 전체 참여의 경우 Entity type을 관계에 이중선으로 연결하고, 부분 참여는 단일선으로 연결함.
- 전체참여: Entity안의 모든 것들이 관계에 참여하는 것.(예: 사원은 하나이상의 프로젝트에 반드시 참여한다.)
- 부분참여: Entity안의 일부분이 관계에 참여하는 것.(예: 사원 중 일부만 부서의 관리자로 참여한다.)
- 읽을 때: 사원-WORKS_FOR-부서 이면, 모든 사원들은 하나의 부서에서 일한다.
사원-MANAGES-부서 이면, 어떤 사원은 하나의 부서를 관리한다.
- Relation type도 Attribute를 가질 수 있다.
- relation 의 attribute는 참여하는 Entity type 중 하나로 이동됨. 1:1 경우에 해당.
예: 어떤 사원이 부서를 담당하기 시작한 날은 부서 Entity 또는 사원 Entity로 가면 됨.
- 1:N의 경우 N측의 Entity type으로 간다. 예: 한 사원이 부서에서 일하기 시작한 날은 사원 Entity의 Attribute로 가야 한다.
- M:N의 경우는 반드시 관계로 명시되어야 한다. 이 relation 자체가 하나의 Entity type으로 만들어지고, 논리 모델링할 때 Table이 된다.
예: 사원이 프로젝트에서 일한 시간의 경우 사원과 프로젝트의 조합에 의해 결정되기에 Relation 자체가 Entity가 되어야 한다.
- Weak Entity type은 Key attribute가 없는 타입을 말하며, Key attribute가 있으면 strong entity type이라고 함.
- 약한 엔티티 타입의 경우 attribute 중하나가 다른 Entity type의 attribute와 연계되어 식별된다.
- 이때 다른 Entity type을 identifying(식별) entity type 이라고 한다.
- 약한 엔티티의 경우 식별 엔티티가 없으면 식별이 안되므로 식별 관계에 반드시 전체 참여 제약조건을 갖음.
- 각 사원과 그 사원의 부양 가족은 약한 엔티티 타입으로 표현된다.
- 약한 엔티티 타입은 partial key(부분키)를 갖고, 해당 attribute에서는 ER 모델에서는 밑줄이 아닌 점선을 긋는다.
- 요구사항에서 명사는 엔티티, 동사는 관계로 표현한다.
- Attribute는 엔티티 타입에 대응하는 명사를 설명하는 부가적인 명사에서 얻음.
- 관계모델은 TedCodd가 처음 소개함. 수학적 relation 개념을 사용하는데 relation은 table의 형태를 가짐.
- 행은 tuple, 열은 attribute, 테이블은 relation이다. attribute의 타입, 저장 포맷을 도메인 이라고 볼 수 있음.
- relation에 있는 attribute의 수를 relation의 degree라고 함.
- 관계 대수
- Select(Where 절로 행선택하는 것), Project(Select 절 사용해서 열선택) : SQL에서는 Select query 하나로 모두 가능
- 카티션 곱= 크로스프로덕트 = 크로스 조인
- Two Phase Locking Protocol(2단계 락킹): 확장단계(트랜잭션은 lock만 수행하고 unlock은 불가능), 축소단계(unlock만 가능하고, lock은 불가능)를 통한 locking.
8. 데이터 추상화(data abstraction)를 통해 원하는 부분만 볼수 있음.
- 데이터 모델: 데이터베이스의 구조를 명시하여 추상화에 필요한 수단 제공, 검색과 갱신을 수행하는 연산들 포함.
- 데이터베이스 구조: 데이터 타입, 관계, 제약조건들.
9. 데이터 모델
- 저수준 또는 물리적 데이터 모델: 데이터가 어떻게 컴퓨터에 저장되는가를 명시, 레코드 형식, 접근 경로 같은 것.
- 고수준 또는 개념적 데이터 모델: 사람들이 데이터를 인식하는 방식에 대한 개념. Entity, Attribute, relationship 개념을 사용.
Entity는 사원이나, 프로젝트 같은 실세계의 개념이고,
Attribute는 사원의 이름이나 급여 같은 Entity의 특성,
Relationship은 사원과 프로젝트 사이의 관계처럼 두 개 이상의 Entity 사이의 연관성을 의미.
10. DB Schema(내포, intension): DB에 대한 기술, 하나의 Entity에 대한 Attribute를 정의
- 예: Student: Name, Student_Number, Major
- Schema와 제약조건을 메타데이터라고 부르며, DBMS 카탈로그에 저장함.
11. DB snapshot(occurence, instance, 현재 상태, 외연, extension)
- 특정 시점에서 DB에 있는 데이터.
12. 3단계 Schema 아키텍처: 물리적 DB와 사용자의 응용프로그램을 분리
- 내부 단계(internal level, internal schema(내부 스키마)): 데이터베이스의 물리적 저장구조 기술, DB 접근 경로 같은 것 기술
- 개념 단계(Conceptual level, conceptual schema(개념스키마)): 모든 사용자들을 위한 전체 DB 구조 기술, 즉, Entity, relationship, data type, constraint 기술.
- 외부 단계(external level, view level(뷰 단계)): 사용자가 관심있어 하는 부분만 보임
- 최종 사용자 ⇔ 개념스키마 ⇔ 내부스키마 ⇔ 저장된 DB
13. 데이터 독립성을 위해 3단계 Schema 아키텍처를 사용함.
- 논리적 데이터 독립성: 외부 스키마나 응용프로그램을 변경하지 않으면서 개념 스키마를 변경하는 것.
DB 확장, 제약조건 갱신을 하여 개념 스키마를 변경할 때, 외부스키마가 영향을 받아서는 안됨.
- 물리적 데이터 독립성: 개념스키마를 변경하지 않으면서 내부 스키마를 변경할 수 있는 것.
또한 외부 스키마 역시 변경할 필요가 없음.
예: 레코드 검색 성능 높이기 위해 알고리즘을 바꾸는데 개념 스키마나 외부 스키마가 변경될 필요는 없다.
14. DBMS 사용시 tier
- 2tier: DBMS 연결시 ODBC 같은 API로 통신
- 3tier: 웹서버 같이 Client가 요청하면 웹서버로 요청이 가고, 웹서버에서 허가받지 않은 사용자를 걸러내기도하며, 이 요청을 DBMS로 다시 보냄.
15. Entity-Relationship 모델 (ER 모델): 고수준의 개념적 데이터 모델
16. ER 다이어 그램
 |
| <ER 다이어그램> |
key는 unique와 minimal 속성을 갖는다.
복합키(composit key)의 경우 여러개의 attribute에 밑줄을 긋는다.
- 엔티티 타입이 key를 갖지 않는 경우 weak entity type 이라고 한다.
- 다치(multivalued) attribute: 자동차 색깔 같이 여러개의 값을 갖을 수 있는 것. 두 줄로 된 타원으로 그림. 중괄호로 표시
- 복합(complex) attribute: 이름, 주소 같은 것.
- 한 Entity type이 다른 Entity type을 참조할 때, 두 Entity 사이에서는 Relationship이 성립되며, ER 모델에서는 이런 참조들을 attribute로 표현하지 않고,
관계로 명시해야 한다.
- relationship type은 ER 모델에서 다이아몬드 모양으로 나타내며, 관계에 참여하는 Entity들은 직선으로 연결되고, 관계이름이 다이아몬드 모양 안에 나타난다.
- 관계차수: 관계에 참여하는 Entity type의 개수, 2개면 binary, 3개면 ternary(삼진)
- 참여 제약: 전체 참여의 경우 Entity type을 관계에 이중선으로 연결하고, 부분 참여는 단일선으로 연결함.
- 전체참여: Entity안의 모든 것들이 관계에 참여하는 것.(예: 사원은 하나이상의 프로젝트에 반드시 참여한다.)
- 부분참여: Entity안의 일부분이 관계에 참여하는 것.(예: 사원 중 일부만 부서의 관리자로 참여한다.)
- 읽을 때: 사원-WORKS_FOR-부서 이면, 모든 사원들은 하나의 부서에서 일한다.
사원-MANAGES-부서 이면, 어떤 사원은 하나의 부서를 관리한다.
- Relation type도 Attribute를 가질 수 있다.
- relation 의 attribute는 참여하는 Entity type 중 하나로 이동됨. 1:1 경우에 해당.
예: 어떤 사원이 부서를 담당하기 시작한 날은 부서 Entity 또는 사원 Entity로 가면 됨.
- 1:N의 경우 N측의 Entity type으로 간다. 예: 한 사원이 부서에서 일하기 시작한 날은 사원 Entity의 Attribute로 가야 한다.
- M:N의 경우는 반드시 관계로 명시되어야 한다. 이 relation 자체가 하나의 Entity type으로 만들어지고, 논리 모델링할 때 Table이 된다.
예: 사원이 프로젝트에서 일한 시간의 경우 사원과 프로젝트의 조합에 의해 결정되기에 Relation 자체가 Entity가 되어야 한다.
- Weak Entity type은 Key attribute가 없는 타입을 말하며, Key attribute가 있으면 strong entity type이라고 함.
- 약한 엔티티 타입의 경우 attribute 중하나가 다른 Entity type의 attribute와 연계되어 식별된다.
- 이때 다른 Entity type을 identifying(식별) entity type 이라고 한다.
- 약한 엔티티의 경우 식별 엔티티가 없으면 식별이 안되므로 식별 관계에 반드시 전체 참여 제약조건을 갖음.
- 각 사원과 그 사원의 부양 가족은 약한 엔티티 타입으로 표현된다.
- 약한 엔티티 타입은 partial key(부분키)를 갖고, 해당 attribute에서는 ER 모델에서는 밑줄이 아닌 점선을 긋는다.
- 요구사항에서 명사는 엔티티, 동사는 관계로 표현한다.
- Attribute는 엔티티 타입에 대응하는 명사를 설명하는 부가적인 명사에서 얻음.
- 관계모델은 TedCodd가 처음 소개함. 수학적 relation 개념을 사용하는데 relation은 table의 형태를 가짐.
- 행은 tuple, 열은 attribute, 테이블은 relation이다. attribute의 타입, 저장 포맷을 도메인 이라고 볼 수 있음.
- relation에 있는 attribute의 수를 relation의 degree라고 함.
- 관계 대수
- Select(Where 절로 행선택하는 것), Project(Select 절 사용해서 열선택) : SQL에서는 Select query 하나로 모두 가능
- 카티션 곱= 크로스프로덕트 = 크로스 조인
댓글 없음:
댓글 쓰기