DB
자료구조
순차적인 선형구조 => 메모리 상에 연속적임
Tree Degree => 가지수, Level => 부모부터 끝까지 레이어 수
DB의 특성과 기능
특징 4
통합된(중복 없음), 운영(일처리에 필요), 공용(모두의 접속을 제어), 저장된
기능 3
정의, 조작, 제어(무결, 보안, 병렬)
DB 설계
설계 고려 6
무결성
삽입, 삭제, 갱신 등 연산 후에도 제약조건을 유지,
제약조건은 현실세계의 값이 데이터 값과 같아지기 위해 필요한 조건임
일관성 - Transaction 전후에 총 값 등이 유지되는 그런거.
회복, 보안, 효율성,
DB 확장 - DB 운영에 영향을 주지 않으면서 지속적으로 추가 가능
설계 순서
요구조건분석 ->
개념적 설계 ->
DBMS 와 독립적인 개념 스키마 모델링, 트랜젝션 모델링.
데이터 모델
구성요소
개체(Entity)
한개 이상의 속성과 관계로 이루어짐(관계는 속성-개체 관계도 있으니)
약어 안쓰고, 단수로 명명.
속성(Attribute)
데이터베이스의 가장 작은 논리적 단위
속성의 수를 Degree 라고 함
속성 특징에 따른 분류
기본속성(Basic Attribute) - 업무에서 분석, 단 코드 제외
설계속성(Designed Attribute) - 설계 과정에서 필요, 코드 포함
파생속성(Derived Attribute) - 기존 속성을 계산, 변형. 없는게 좋음
개체 구성에 따른 분류
기본키 속성(Primary Key Attribute)
외래키 속성(Foreign Key Attribute), 일반속성
원시 속성(Source Attribute) - 다른 속성으로 재현 불가능한 속성
동사로 명명하면 안댐
관계
개체 간 관계, 개체 - 속성 간 관계가 있음.
관계의 형태 => 1:1, 1:N, N:M 관계가 있음
관계의 종류
종속 관계(Dependent Relationship)
식별 관계(Identifying Relationship)
foreign key 를 들고오는데(당연히 외부 객체의 기본키)
그게 나의 primary key 인 경우 - 존재 종속적, 실선
비식별 관계(Non Identifying Relationship)
foreign key 를 들고오는데(당연히 외부 객체의 기본키)
그게 나의 non-primary key 의 경우 - 존재 독립적, 점선
중복 관계(Redundant Relationship) - 종속 2개 이상. 없는게 좋음
재귀 관계(Recursive Relationship) - ㅈㄱㄴ
배타 관계(Exclusive Relationship)
Exclusive And Relationship - 하위 객체 중 하나만 선택 가능함
Exclusive Or Relationship - 하위 객체 중 여러개 선택 가능함
표시할 요소 (***개중요***)
구조(Structure) - Relation 등,
연산(Operation)
관계대수(Relational Algebra) - 절차적
관계해석(Relational Calculus)
비절차적, 질의어, 관계대수와 처리력 동등
튜플 관계해석, 도메인 관계 해석이 있다.
수학의 Predicate Calculus 가 모델
제약조건(Constraint)
식별자, Identifier - 구성요소는 아님
특성4
유일성(Unique)
instance 를 구분할 수 있어야 하며
잠재적인 중복이 없도록 개념적으로 유일해야함
최소성(Minimality, 최소 수), 불변성(read only), 존재성(null x)
후보식별자
하나 이상 반드시 존재하는 식별자, 주/보조로 될 운명
Primary Identifier(주 식별자)
후보 식별자 중 개체를 대표할 유일한 식별자
존재성(null x), 값은 자주 변경되지 않아야 함.
Alternate Identifier(Secondary ID, 보조 식별자)
유일한데 대표만 아님, 여러개 가능.
Unique Index 로 지정해 사용
Internal Identifier(내부 식별자) - 개체 내에서 만들어짐, recursive
External Identifier(외부 식별자) - 개체 외에서 가져옴, Foreign Key
Single Identifier(단일 식별자) - 속성 하나로 구성.
Composit Identifier(복합 식별자) - 속성 여러개로 구성
Original Identifier(원조 식별자) - 있던 거 쓰는거.
Surrogate Identifier(대리 식별자)
복수를 하나로 합침 or 의미적 이유로 새로 만듬
Integrity(무결성)
데이터 값이 현실과 일치하기 위해서 만든 조건
Entity Integrity(개체 무결성) - 기본키 NULL 아님
Domain Integrity(도메인 무결성) - 속성 값이 도메인 밖 안댐
Referential Integrity(참조 무결성)
외래키는 NULL 또는 참조 릴레이션의 기본키만 가능
즉 참조 릴레이션의 기본키의 도메인과 속성 갯수는 자신과 같음
CASCADE 법칙 - 외래키 등 연관된 값들도 같이 삭제된다는 법칙
User-Defined Integrity(사용자 정의 무결성) - ㅈㄱㄴ
적용
어플리케이션 - 복잡 구현 가능, 관리가 힘들고 적정선 검토 힘듬
데이터베이스 트리거 - 통합 관리, 복잡 구현 가능, 변겅 어렵
제약조건 - 간단하고 통합 관리 가능, 복잡 구현 불가능
모델 종류
개념적 데이터 모델
인간이 이해하기 위한 모델
E-R 모델 + ERD(ER-Diagram)
30, 데이터베이스 설계 산출물,
개체간의 관계를 기본 요소로 이용하여 현실세계를 모델화
피터 첸 포기법(Peter Chen Notation)
사각형 - 개체, 마름모 - 관계, 타원 - 속성
이중타원 - 다중속성, 밑줄타원 - 기본키속성
복수타원 - 복합속성
정보 공학 표기법(Information Engineering Notation)
1 => 1개, 0 => 0개, ∈ => N개 가 복합적으로 사용
A->B 의 관계를 볼 때 B 쪽의 0, |, ∈ 를 살펴봄
바커 표기법(Barker Notation)
점선은 0, 1개, 실선은 1개, ∈ => N개 덧붙임.
선에는 관계에 대한 개체의 역할을 동사로 표기
속성별로 * 는 필수, o 은 nullable, # 은 기본키
A->B 의 관계를 볼 때 A 쪽의 점실선, B 쪽의 ∈ 를 살펴봄
논리적 데이터 모델 - 컴퓨터용 모델.
관계 모델
간결하고 보기 편하며, 다른 DB로 전환이 쉬운데 좀 느림.
튜플 사이에는 순서가 없다(물리적 저장에는 있을지라도)
속성값은 논리적으로 더 이상 쪼갤 수 없는 원자값이다.
카디널리티(Cardinality) - 튜플 수 = row 수
차수(Degree) - 속성 수, Domain - 속성 범위
계층 모델,
네트워크(망) 모델
Onwer-Member 관계
물리적 데이터 모델
Transaction
Atomicity(원자성)
드랜잭션이 되거나 안되거나
Consistency(일관성),
Isolation(독립성, 격리성, 순차성)
둘 이상 실행 중 다른 트랜잭션이 끼어들 수 없다.
Durability(지속성, 영속성)
완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영
논리적 설계 ->
스키마, 트랜잭션 인터페이스
개념적 설계에서 만들어진 정보 구조에서 물리적 구조로 변환하는 과정
정규화
동기
데이터는 원래 종속적임.
근데 테이플 하나에 다 표현하면 속성 간 종속으로 이상이 발생함
이상(Anomaly)
삽입 이상 - 내가 모르는 속성이 많아서 원치않는 null 등으로 채움
삭제 이상 - 학생튜플을 지웠는데 학과 속성도 없어짐
갱신 이상 - 중복이 너무 많아서 일관성유지 못함
그래서 정보 무손실 + 테이블 분리 + 데이터 중복 감소 하기로 함
1NF - 원자값 정돈
속성이 여러개의 값이 아닌 원자값(Atomic Value) 를 가짐
2NF - 기본키 정돈
(ID, 이름)(기본키) 로 회원번호가 결정되는데 ID 만으로도 결정된다?
기본키가 복합일 때 다른 속성이 기본키의 일부에 대해 종속적임 안댐
그럴거면 따로 빼지. 위는 부분함수적 종속이라 부름.
그래서 기본키에 대해 다른 모든 각각의 속성이 완전함수적 종속만 댐
3NF - 필드 정돈
ID(기본키) 로 우편번호가 결정되고 우편번호로 주소가 결정이 된다?
기본키로 A->B , B->C => A->C 인 이행적 종속 금지
기본키에 대해 (Transitive Dependency) 금지
정보의 무손실 표현(종속성 유지)가 되는 마지노선
BCNF(Boyce-Codd NF)
필드에 몬스터가 레벨별로 1마리씩 들어감
(필드, 레벨)(기본키)로 몬스터ID가 결정되는데 이 ID 가 레벨을 결정?
레벨 대신 ID 넣고 레벨 빼는게 나음.
그래서 결정자는 무조건 후보키어야만 함
(후보키는 1:1 대응이라 어쩔 수 없음)
4NF - 결합도
서로 독립적인 속성이 기본키 하나에 묶여있는 경우
MVD(Multi Valued Dependency, 다차종속)
A->>B, B가 A에 대해 종속적이고 A는 B와 독립인 다른 속성과도 관계
다차종속 A->>B 가 성립시 R 의 모든 속성이 A에 대해 종속관계여야 함.
뭔말이면 A가 서로 독립적인 속성 B, C 중 B 를 결정짓는다고 하자.
그럼 A->B 에 대해서 C 의 도메인 갯수만큼 데카르트 곱이 필요할 거임.
왜냐하면 C 는 B와 독립적이니까.
이러면 중복된 값이 많고 동시에 A->C 가 성립하지 않음.
그래서 테이블 하나 빼서 A->C 인거 만듬.
5NF - 결합도
R 가 A join B 으로 나타낼 수 있으면 따로 하는게 좋지 않음?
Join Dependency(조인 종속)
select 로 구성한 부분집합으로 join 할 때 자신이 되면 성립
모두 따로 만들면 조인 종속은 후보키에서만 성립하게 됨
반정규화
처리속도나 보안 등을 위해 의도적으로 정규화 안함
테이블 통합
Join 등 두 테이블이 자주 함께 사용되는 경우
1:1, 1:N, 슈퍼타입/서브타입 통합이 있어 레코드 증가 가능성 큼
슈퍼타입/서브타입 통합
슈퍼타입 기준 테이블 변환
조인 안해도 되고 뷰로 조회 삭제 가능
서브타입 구분 필요
서브타입 기준 테이블 변환
서브타입 구분 안해도 됨.
여러 테이블 통합된 뷰는 수정 불가능
개별타입 기준 테이블 변환
슈퍼타입 - 서브타입 은 1:1 관계임. 1:M 아님
용량이 덜 먹음
조인이 항상 발생해서 느림.
테이블 분할
수평분할 - 레코드별 빈도차이 큰 경우
수직분할
갱신 위주
레코드 잠금으로 다른 속성에 대한 검색도 안댐
자주 갱신되는 속성만 뺌
조회 위주 - ㅈㄱㄴ
크기가 큰 속성 - ㅈㄱㄴ
보안 위주 - 특정 속성에만 보안 적용하고 싶을 때
기본키의 유일성 관리가 어려워짐
중복 테이블 추가
집계 테이블 추가(트리거로 동기화), 진행 테이블 추가(이전 속성 값) 등
중복 속성 추가
데이터를 조회하는 경로 - 조인 을 단축
기본키가 여러개로 구성되어 더러울 경우
SQL Group Function(Sum, Avg 등) 으로도 해결될 수도 있으니 유의
물리적 설계 ->
응답 시간, 저장 공간의 효율성, 트랜잭션 처리율 고려해 옵션 선택
데이터 명명 규칙
논리 데이터베이스 설계와 데이터 표준화 등으로 파악
데이터 사전에 논리명, 물리명(자료형), 용어 정의를 기록 및 조회
물리적 데이터 모델
컬럼
Attribute 에 대응. Data Type, Length로 구성.
고정길이는 앞쪽, 가변길이나 NULL이 많을거 같으면 뒤쪽에 저장됨
참조관계는 타입과 길이 둘 다 엄격히 같아야 함
비교는 길이정도는 DBMS가 변환해 수행가능
Key
식별자의 물리적설계에 대응함
Super Key(슈퍼키)
튜플을 유일하게 식별 가능한 속성들의 부분집합
유일성 만족, 최소성 만족 안함
Candidate Key(후보키)
슈퍼키 중 최소성도 만족. 즉 유일성, 최소성을 만족해야함
Primary Key(기본키) - NULL 안댐
Alternate Key(보조키)
Foreign Key(외래키)
속성 A가 참조 관계의 기본키 B와 동일한 도메인을 갖음
참조 릴레이션에 없는 값은 입력 불가능
Unique Key(유니크키) - 해당 속성의 값이 각각 유일함 보장
Table
일반 테이블 - 데이터가 저장되는 순서에 따라 저장
클러스터 테이블
단일 테이블 클러스터링
기본키나 인덱스키 순서에 따라 저장
다중 테이블 클러스터링
Clustering Key 로 지정된 컬럼 값의 순서대로 저장
장점
대량 범위 조회가 빨라짐
Clustering Key 로 하는 Join 에서 매우 성능 높아짐
Clustering Key 열은 공유되어 디스크 용량 줄어듬
단점
입력, 수정, 삭제는 저하됨
전체스캔하면 장점이 퇴색됨 => 대용량 처리 트랜잭션 지양
Clustering Key 열은 공유되므로 데이터 분포도가 넓을 수록 좋음
인덱스 속성처럼 ORDER BY, GROUP BY, UNION 많으면 좋음
파티셔닝 테이블
대용량 파일의 열을 Partition Key 나 Index Key 에 따라 물리적 분할.
데이터 처리는 테이블 단위로, 데이터 저장만 파티션별로 됨.
장점 - 분산에 따른 성능 향상
단점 - Join 시 비용이 매우 큼
분할 종류
범위 분할,
해시 분할 - 데이터를 고르게 분산
조합 분할(Range + Hash)
범위 분할한 파티션이 너무 클 때 해시 분할을 적용
인덱스 파티션
테이블을 나누면 인덱스도 파티션 해야함.
Local Prefixed Partitioned Index
테이블 파티션과 인덱스 파티션이 일대일 대응
인덱스 파티션 키와 인덱스 첫번째 컬럼이 같음.
Local Non-Prefixed Partitioned Index
테이블 파티션과 인덱스 파티션이 일대일 대응
인덱스 파티션 키와 인덱스 첫번째 컬럼이 다름.
인덱스 파티션 키를 이용한 최소범위 스캔에 유용
이력성 데이터(보관용 데이터)에 날짜를 파티션 키로 많이 쓰임
Global Prefixed Partitioned Index
테이블 파티션과 인덱스 파티션이 일대일 대응 안함.
인덱스 파티션 키와 인덱스 첫번째 컬럼이 같음.
보통은 인덱스 파티션이 여러 테이블 파티션을 포괄하는 구조
경합 분산용 외엔 거의 안쓰임
Global Non-Prefixed Partitioned Index - 없음
외부 테이블(External Table)
외부 파일로 디비 내에 객체로 존재함
Data Ware-house 의 ETL 작업에 활용
Data Ware-house
주요업무 시스템에서 의사결정지원시스템을 위해 추출된 데이터
데이터 웨어하우스에서 ETL(Extraction, Transformation, Loading) 함
임시 테이블
트랜젝션의 절차적 진행을 위해 임시적으로 저장된 파일
Relation
1:1, 1:M, 1:M 순환은 외래키로 표현
N:M 관계는 교차 관계(Intersection Relation) 을 사이에 추가해야함
저장공간 설계
테이블 스페이스, 테이블, 데이터로 나눠 관리 시
논리적 구성이 물리적 구성에 종속되지 않아 투명성 보장
테이블 스페이스
테이블이 저장되는 논리적인 공간
테이블, 인덱스, 임시파일, 대용량파일 등 용도에 따라 만듬
마스터 테이블과 트랜잭션 테이블로 용도로도 분류함.
설계
맨 위는 DB 가 분산. 아래 두개는 서버가 분산되어 안정성 올림
분산 데이터베이스 설계
분산 처리기, 분산 데이터베이스, 통신 네트워크로 구성
전역 관계망을 논리적 측면에서 소규모 단위(Fragment)로 분할
그 결과를 복수의 노드에 할당(Allocation)
물리적으론 네트워크로 연결, 논리적으론 하나로 존재
투명성(Transparency)
Location Transparency(위치 투명성)
실제 위치는 다르지만 DB 의 논리적 명칭만으로 엑세스 가능
Replication Transparency(중복 투명성)
실제론 중복저장이나 마치 하나의 데이터만 존재하는 것처럼.
Concurrency Transparency(병행 투명성)
다수의 트랜잭션들이 동시에 실현되도 결과는 영향받지 않음
Failure Transparency(장애 투명성)
트랜잭션, DBMS, 네트워크 장애에도 트랜잭션을 정확히 처리
테이블 위치 분산
테이블 수정 없이, 중복되지 않게 서버 위치만 다르게.
분할(Fragment)과 할당(Allocation)
분할(Fragment)
완전성(Completeness) - 전체 데이터를 대상으로
재구성(Reconstruction) - 본래의 데이터로 재구성 가능
상호 중첩 배제(Disjointness) - 분할된 데이터는 중첩되지 않음
수평 분할 / 수직 분할 이 있음
할당(Allocation)
동일한 분할을 여러개의 서버에 생성
비중복 할당 방식 - 테이블간 의존성이 무시되 비용증가함
중복 할당 방식 - 대개 많이 사용. 부분복제 / 전체복제
Database Replication(데이터베이스 이중화)
Eager 기법 - 트랜잭션 중 변경이 있으면 모든 DB에 즉시 적용
Lazy 기법 - 로컬의 트랜잭션과 DB 간 트랜잭션이 독립적. 빠름
Active-Standby 기법 - 쉬고 있다가 터지면 다른게 돌아감
Active-Active 기법 - 둘다 돌다가 하나 터지면 혼자 돌아감
Clustering
두 대 이상의 서버를 하나의 서버처럼 이용
서버 이중화 및 공유 스토리지(NAS, Network Attacthed Storage) 이용
고가용성 클러스터링 - 서버가 독립적으로 작업, 보통 이걸 말함
병렬 처리 클러스터링 - 서버가 하나의 작업을 분산해서 처리
CRUD 분석
Create, Read, Update, Delete
CRUD Matrix
행에는 프로세스를 열에는 테이블이 있음
안에는 C > D > U > R 의 우선순위로 하나만 적거나 다 적음
테이블이 CRUD 모두 없거나 R 이 없으면 쓸데가 없고
테이블에 C 가 없으면 생성이 안된거
프로세스에 CRUD 모두 없으면 DB에선 고려할 필요 없으니 제거 검토
Transaction 분석서
CRUD Matrix 를 이용함
프로세스 명, CRUD 연산, 테이블 명, 컬럼명, 참조횟수, 트랜잭션 수, 주기
Index
Clustered Index
저장 순서와 인덱스 순서가 같도록 유지되는 인덱스
빠르고 테이블 당 하나만 가능
트리 기반 인덱스
B Tree Index
B+ Tree Index
인덱스 세트(Index Set, 비교용), 순차 세트(Sequence Set)
순차 처리, 순차 검색시 순차 세트 이용 가능
비트맵 인덱스
컬럼들의 데이터가 Bit 값인 0, 1 로 변경되어 저장됨.
분포도(조건 맞는 레코드/전체레코드) 가 낮은 컬럼에 적합.
다중조건, 논리계산 유리. 압축 잘됨. 공간 적게 먹음.
Non Clustered Index
저장 순서와 인덱스 순서가 다른 인덱스
느리고 테이블 당 여러개 가능. 보조 인덱스로도 잘 쓰임
함수 기반 인덱스
특정 함수에 적용된 결과값을 이용.
B+Tree, Bitmap Index 를 생성하여 사용함.
Arithmetic Expression(산술식), 사용자 정의 함수, PL/SQL Function
, Package, C callout 등의 함수가 사용됨
Bitmap Join Index
다수의 조인된 객체로 구성. 테이블 조인할 때 임시로 만드는 것.
그래서 일반적인 인덱스와 액세스 방법이 다름.
물리적 구조는 비트맵 인덱스랑 같음.
조인 후 where 문으로 검색할 때 등 조인 후 그 일부만 쓸 때에
비트맵 조인 인덱스를 써서 조건 처리를 빨리 끝낼 수 있음
Domain Index(Extendable Index) - 사용자 지정 인덱스
Concatenate Index(결합 인덱스)
여러 컬럼을 묶어서 하나의 인덱스로 만듬
(Dept Name, Salary) 순이면 Dept Name 이 우선수위가 높음.
그래서 select Dept_Name > 9000 and Salary = 100 이거 안댐
Storage
DAS(Direct Attached Storage) - 싼데 공유 안됨
NAS(Network Attached Storage)
사용자와 서버의 연결인 Ethernet 스위치로 Storage 가 연결
네트워크 접속량 많으면 느려짐
SAN(Storage Area Network)
서버와 Storage 를 연결하는 독립적 네트워크 Fiber Channel(FC) 설치
초기 네트워크 구축비가 큼
구현
트랜젝션 작성, DDL 로 DB 작성 및 컴파일, 파일 작성
View
물리적으로 존재하지 않지만, 사용자에겐 있는 것으로 간주됨
뷰 기반으로 뷰 생성 가능
장점
조인문의 사용 최소화로 사용자 편의성이 최대화 됨
인라인뷰(From 절 안에 들어가는 서브쿼리) 대체 가능
특정 컬럼 안보이게 보안 강화
단점
독립적 인덱스 없고, 뷰 정의 변경 안되고,
삽입 삭제 갱신 연산에 제약
기본키 미포함, 생성시 From 에 여러 테이블, group by 으로 생성 등
DB 모듈
데이터 정의어 번역기(DDL Compiler), 데이터 조작어 번역기(DML Compiler)
Data Directory
Data Dictionary 에 접근하기 위한 정보 관리 유지, 시스템만 접근 가능
Data Dictionary (System Catalog)
모든 데이터 객체들에 대한 정의, 명세 유지관리
여러 스키마와 이들 간의 사상(Mapping)에 대한 정보 관리
질의 최적화기, 트랜잭션 처리기(사용자 간 배타적 접근)
보안
테이블부터 특정 행, 열까지 적용가능
Encryption(암호화)
Private Key Encryption(비밀키 암호 방식, 개인키 암호방식)
동일한 키를 권한 있는 사용자들만 나눠 가짐.
DES(Data Encryption Standard), 전위, 대체(Substitution), 대수 기법
Public Key Encryption(공개키, 공중키 암호 방식)
암호화에 쓰이는 공개키는 사용자에게 공개하고
복호화에 쓰이는 비밀키는 관리자가 비밀리에 보관
RSA(Rivest Shamir Adleman)
Decryption(복호화)
접근통제(Access Control)
접근통제 정책
신분기반 정책=DAC(Discretionary Access Control, 임의 접근 통제)
객체를 생성한 사용자가 사용자의 신원에 따라 접근 권한을 부여
SQL 의 GRANT, REVOKE 로 구현
IBP(Individual-Based Policy) : 단일 주체 별 하나의 객체에 대한 허가
GBP(Group-Based Policy) : 복수 주체 별 하나의 객체에 대한 허가
규칙기반 정책=MAC(Mandatory Access Control, 강제 접근 통제)
객체를 생성한 자와 관계없는 제 3자가 접근통제 권한 지정
MLP(Multi-Level Policy) - 사용자 및 객체별로 지정된 기밀 분류에 따름
CBP(Compartment-Based Policy) - 객체의 집단별로 지정된 기밀 허가에 따름
역할기반 정책 - GBP 의 변형으로 주체의 신분이 아니라 역할에 근거
접근통제 매커니즘
접근통제목록(Access Control List) - 객체에게 어떤 주체가 어떤 행위가?
능력리스트(Capability List) - 주체에게 허가된 자원 및 권한
보안 등급(Security Level) - 객체, 주체에 부여된 보안 속성의 집합
패스워드, 암호화
위를 통해서 접근통제 정책이 구현됨
접근통제 보안모델
보안정책을 구현하기 위한 정형화된 모델
기밀성 모델
군대에서 쓰임. 낮은 등급에 쓰기 방지용
인가된 사용자만 읽기 가능
단순 보안 규칙(위에거 못읽음), 스타 보안 규칙(아래거 못씀)
강한 스타 보안 규칙(같은 등급만 읽쓰)
무결성 모델
기밀성 모델의 불법적 정보 변경 방지 및 데이터 일관성 유지를 위해
인가된 사용자만 쓰기 가능
단순 무결성 규칙(아래거 못읽음), 스타 무결성 규칙(위에거 못씀)
접근통제 모델
주체를 행, 객체를 열로 하는 Access Control Matrix 이용
접근통제 조건(부가적)
접근 통제 매커니즘 취약점 보안, 접근통제 정책에 부가하여 적용
Value-Dependent Control - 특정 값에 따라 튜플이 허용될지 말지
Multi-User Control - 동시 접근을 요구시 해줄지 말지
Context-Based Control - 특정 시간, 네트워크 주소, 접근 경로 등
백업
로그
데이터베이스 상태를 일관성 있게 유지시켜줌
작업 순서가 아니라 시간 순서대로 기록되는 거니 주의
복구 알고리즘
No-Undo/Redo - 버퍼의 내용이 비동기적으로 DB에 기록
Undo/No-Redo - 버퍼의 내용이 동기적으로 DB에 기록
No-Undo/No-Redo - 버퍼의 내용이 DB 말고 다른영역
Undo/Redo - 버퍼의 내용이 비동기/동기적으로 DB에 기록
백업 종류
물리백업
OS 에서 데이터를 통째로 복사함. 그래서 로그파일도 백업됨.
로그파일이 따로 백업되어 있으면 완전백업 가능. 아님 백업시점까지
논리백업
DBMS가 로그파일 등 유틸리티를 이용해 백업함.
백업시점까지만 복구됨
전문 용어
SQL Mapping(JDBC, ODBC)
ORM(Object Relational Mapping, JPA, Django)
TCL(Transaction Control Language, Commit, Rollback, Savepoint)
Data Mapping(객체-데이터 매핑)
Extent - 92, 기본적인 용량이 모두 찼을 때 추가적으로 할당되는 공간
댓글 없음:
댓글 쓰기