🌚 DB, DB 설계 과목

• DB, DataBase
  • 방정리를 왜 할까 : 잘 찾을려고! (잘 보관하려고가 아니라)
  • 데이터도 메모장으로 저장하는 것보다 찾을 때 천배 낫다

  • 제목 (문자열)로 찾는 것보다 분류로 찾는 게 빠르다

  • No Index : 전부 다 뒤진다
  • SQL : 정형화, 대기업, 실수를 절대로 하면 안될 때
  • NoSQL : 비정형화, 앞으로 뭔가 많이 바뀔 때

---

• WHAT
  • DB, DBMS, Data Model (Kind), DB System
  • DB 개념 (4), 특징 (4)
  • File System VS DB (데이터 접근 방법 등)
  • 3단계 구조, 데이터 독립성
  • 2-Tier, 3-Tier

---

엔터프라이즈?
포탈?

DB : 단순 데이터 저장, 저장물, 데이터 집합체
DB 시스템 : 데이터 저장 과정/체계, DB 생산 공장

아웃라인을 보자

파일 시스템과 DBMS의 차이

DB 시스템의 컴포넌트들

사람,이 DBMS,로 데이터,를 DB,로

---

데이터 : 가공이 안된 유무형의 SMT

• 관찰의 결과로 나타난 정량적(크기가 존재) 혹은 정성적인(값으로 측정되지 않는 : 잘한다, 못한다) 실제 값
• 사실(facts, 정성적)이나 값(values: 수치(숫자), 스트링 etc., 정량적)

정보 : 가공된 데이터

• 데이터에 의미를 부여한 것
• 의사결정을 할 수 있게 하는 데이터의 해석이나 데이터 상호간의 관계

지식 : 정보를 활용하여

• 사물이나 현상에 대한 이해

데이터 != 정보
단순 숫자 3개를 그냥 볼 때와 3 사이즈라는 것을 알고 볼 때의 차이

정보처리, 자료처리 : 정보추출방법

DB :
조직에 필요한 정보를 얻기 위해 논리적으로 연관된 데이터를 모아 구조적으로 통합해 놓은 것

---

구축이 쉬움

• 공룡 DB
  • 검색이 많지 않아 DB를 구축할 필요 없음
  • 보존가치가 있는 경우에 구축
• 도서
  • 사용자 수 보통
  • 검색은 많지만 데이터에 대한 변경은 적음
• 비행기 예약
  • 예약 변경/취소 등 데이터 변경은 많지만 검색은 적음
  • 실시간 검색 및 변경이 중요함
• 증권
  • 사용자 수 많음
  • 검색도 많고 거래로 인한 변경도 많음

구축이 어려움

---

DB

한 조직(enterprise)의 여러 응용 시스템들이
공용(shared)하기 위해
통합(integrated), 저장(stored)한
운영 데이터(operational data)의 집합

---

DB 개념

• 통합된 데이터, Integrated data
  • 데이터 통합 → 데이터 중복 최소화, Minimal Redundancy
  • 왜 Why?
    • 중복으로 인한 데이터 불일치 현상을 없앰, Controlled Redundancy
• 저장된 데이터, Stored Data
  • 문서 X, 컴퓨터 저장장치에 저장된 데이터 (디스크, 테이프)
• 운영 데이터 Operational Data
  • 조직의 목적을 위해 사용되는 데이터
  • 업무를 위한 검색을 할 목적으로 저장된 데이터
• 공용 데이터 Shared Data
  • 한 사람/업무를 위해 사용되는 데이터가 아니라, 공동으로 사용되는 데이터

각자 같은 데이터를 가지고 작업할 수도 있지만,
이런 공통 데이터를 통합 Integrate 해서 하나로 정리 = DB 설계

최종적으로 DBMS를 통해 통합 DB 데이터에 접근
DB = 운영 데이터를 통합하여 저장하며 공용으로 사용됨

---

DB 특징

• 실시간 접근성, Realtime Accessibility
  • 실시간 서비스
  • 데이터 요청 시 수 초내에 결과를 서비스
• 계속적인 변화, Continuous Change
  • DB에 저장된 내용은 어느 한 순간의 상태
  • 데이터 값은 시간에 따라 항상 바뀜 : 동적(dynamic) 특성
  • DB는 CRUD를 통하여 바뀐 데이터 값을 저장
• 동시 공유, Concurrent Sharing
  • DB는 서로 다른 업무/사용자들에게 동시에 공유됨
  • 동시(Concurrent)는 병행이라고도 하며, DB에 접근하는 프로그램이 여러 개 있다는 의미
• 내용에 따른 참조, Reference By Content
  • DB에 저장된 데이터는 데이터의 물리적인 위치가 아니라 데이터 값에 따라 참조됨
    • @ 계층 데이터 모델은 포인터를 씀

---

DB 시스템의 구성

• DB 시스템
  • DB - 데이터를 모아둔 토대
  • DBMS - 사용자와 DB를 연결시켜주는 SW
  • 데이터 모델 - 데이터가 저장되는 기법에 관한 내용, DBMS의 청사진

---

• 클라이언트 → 서버 { Apache → PHP (PHP 해석기) = WAS → MySQL } → DB

• 분산 DB 시스템

  • 데이터가 여러 위치에 저장된 DB
  • 대규모의 응용 시스템에 사용됨
  • Distributed Database Types: two types
    • Homogenous :
      • A network of Identical Databases stored on multiple sites
    • Heterogeneous :
      • Different schemas, OS, DDBMS (Distributed ~), and different data models

---

• WAS
  • Web Application Server
• IPO
  • Input Process Output
• Host Language
  • 일반 프로그래밍 언어에 SQL문을 사용하여 각 언어의 장점을 살림
  • = 삽입 프로그래밍 Embedded

---

• SQL, Standard Query Language
  • DDL, Data Definition Language, 데이터 정의어
    • DB에 저장된 테이블 구조 정의
    • CREATE, ALTER, DROP
  • DML, Data Manipulation Language, 데이터 조작어
    • 데이터 검색, 변경(삽입, 삭제, 수정)에 사용
    • SELECT, INSERT, DELETE, UPDATE
  • DCL, Data Control Language, 데이터 제어어
    • 데이터 사용 권한 관리 등
    • GRANT, REVOKE
• Query, 질의문
  • SELECT
  • FROM
  • WHERE

• DBA, DB Administrator

• DBMS의 기능
  • 데이터 정의, Data Definition
    • 데이터 구조 정의, 데이터 구조에 대한 삭제 및 변경 기능 수행
  • 데이터 조작, Data Manipulation
    • 데이터 조작 SW(APP)가 요청하는 데이터 삽입, 수정, 삭제 작업 지원
  • 데이터 추출, Data Retrieval
    • 사용자 조회 데이터, APP 데이터 추출
  • 데이터 제어, Data Control
    • DB 사용자 생성, 모니터링, 접근 제어
    • 백업과 회복, 동시성 제어 등의 기능 지원
• 데이터 모델
  • 개념적 데이터 모델 (Like E-R 모델)
    • 현실 세계의 이해를 추상적 개념으로
  • 논리적 데이터 모델 (일반적으로 데이터 모델이라 한다면)
    • 개념적 데이터 모델을 컴퓨터 논리화
• 데이터 모델
  • 계층 데이터 모델 Hierarchical Data Model
    • 파일 시스템이나 유니티 오브젝트 Hierarchy 같이, 부모:자식 1:N 관계
  • 네트워크 데이터 모델 Network Data Model
    • 망형
  • 관계 데이터 모델 Relational Data Model
  • 객체(지향형) 데이터 모델 Object(-Oriented) Data Model
    • 객체 지향 개념을 완전히 DB에 적용해서 구현하는 것이 쉽지 않음, 관계 데이터 모델에서 점차 확장되어 가는 중
  • 객체ㅡ관계 데이터 모델 ObjectㅡRelational Data Model
• 객체 간의 관계 표현
  • 포인터 사용 : 계층 데이터 모델, 네트워크 데이터 모델
  • 속성 값 사용 : 관계 데이터 모델
  • 객체 식별자 사용 : 객체 데이터 모델
• @ 객체 데이터 모델 vs 관계 모델
  • Class vs Relation/Table
  • Object/Object Instance vs Tuple/Record
  • Variable vs Attribute/Column
  • Method vs Stored Procedure
• @ DBMS Schemas
  • Client : External Level/View Level
  • Server : Conceptual Level/Internal Level
  • DB : Internal Level

---

3단계 DB 구조, 3-Layer DB Architecture

Schema : 조직, 구조 (그리스어)
ER = Entity Elation Model

외부, 개념, 내부
외부-개념, 개념-내부 사이 매핑

Mapping 매핑 = 사상
상호 독립적인 개념을 연결시켜주는 다리

• 외부 단계 External Level
  • DB를 바라보는 User View (User, 응용 프로그래머)
  • 전체 DB 중에서 하나의 논리적인 부분을 의미
  • 1 DB : N * External View (Sub Schema)
  • View 개념 (#구현이 아님)

같은 DB를 쓰더라도,
기능마다 다루는 데이터, 데이터 관계는 다르니까

• 외부/개념 매핑
  • 외부 스키마의 데이터가 개념 스키마와 어느 부분에 해당되는지 대응시킴

외부 스키마 뭉탱이 = 개념 스키마
외부 스키마 = 개념 스키마의 Logical Part

• 개념 단계 Conceptual Level
  • 전체 DB의 정의
  • 1 DB : 1 Conceptual Schema
  • 데이터과 관계, 제약사항, 무결성에 대한 내용이 포함됨
• 개념/내부 매핑
  • 개념 스키마의 데이터가 내부 스키마의 물리적 장치 어디에 어떤 방법으로 저장되는지 대응시킴
• 내부 단계 Internal Level
  • 물리적 저장장치에 DB가 실제로 저장되는 방법의 표현
  • 1 DB : 1 Internal Schema
  • 인덱스, 데이터 레코드의 배치 방법, 데이터 압축 등에 관한 사항이 포함됨

데이터 독립성

하위 단계의 내용을 추상화
상위 단계에 세부 사항 숨김

특정 단계 구조가 변경되어도
다른 단계 구조에 상호간섭없도록

내부 구조가 변경되더라도,
데이터는 기존 그대로 내려올 때
문제 없이 작동할 수 있도록 ?

• 논리적 데이터 독립성, Logical Data Independence
  • 외부/개념 사이의 독립성
  • 개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않도록 지원
  • 논리적 구조가 변경되어도 응용 프로그램에는 영향이 없도록 하는 개념
  • I.E. 개념 스키마와 테이블을 생성하거나 변경
    • 외부 스키마가 직접 다루는 테이블이 아니면 영향이 없음
• 물리적 데이터 독립성, Physical Data Independence
  • 개념/내부 사이의 독립성
  • 저장장치 구조 변경과 같이 내부 스키마가 변경되어도 개념 스키마에 영향을 미치지 않도록 지원
  • 논리적 데이터 독립성보다 구현하기 쉬움
  • I.E. 성능 개선을 위하여 물리적 저장 장치를 재구성할 경우
    • 개념/외부(APP) 스키마에 영향이 없음

---

관계 데이터 모델

릴레이션 Relation
관계 Relationship
이외 그대로 번역, Relation = 관계

• 릴레이션 Relation
  • 행열 테이블
  • 두 집합의 원소끼리 관련시킨다는 수학 용어
    • 유사한 대상들을 관련시키는 성질들의 특정 조합
  • 관계 표기 : R
  • 관계를 맺는 방법 → 집합 연산 - 카티전 프로덕트
  • 각 집합 요소 하나가 서로 관계를 맺고, 관계가 모여 릴레이션
• 관계 Relationship
  • 릴레이션 내에서 생성되는 관계
    • 이런 관계가 모여 릴레이션
  • 릴레이션 간의 관계
    • 관계 데이터 모델의 특징
• 릴레이션 구성
  • 스키마 Schema, 내포
    • 릴레이션이 어떤 정보를 담고 있는지
    • 테이블의 첫 행, 헤더 Header
    • 각 데이터의 특징을 나타내는 속성, 자료 타입 등
  • 인스턴스 Instance, 외연
    • 스키마에 기반, 실제로 저장된 데이터 집합
• 릴레이션 스키마
  • 속성 Attribute : 릴레이션 스키마의 열 Column
  • 도메인 : 속성이 가질 수 있는 값의 집합
  • 차수 : 속성의 개수

릴레이션 이름 (속성 1, )
릴레이션 이름 (속성 1 : 도메인 1, … )

관계 DB 스키마 = 릴레이션 스키마 집합

• 릴레이션 인스턴스
  • 튜플 Tuple : 릴레이션 인스턴스의 행 Row
  • 카디널리티 Cardinality : 튜플의 수
• 릴레이션 ≓ 테이블
  • 릴레이션 : 주로 구조를 강조
    • 수학 집합 이론에 기초, 속성/인스턴스의 중복 허용 X
  • 테이블 : 주로 데이터를 강조
• 릴레이션 특징
  • 속성은 단일 값을 가진다
    • 여러 값을 가질 경우, 튜플을 하나 더 만들어 속성의 값이 단일 값이 되도록
  • 속성은 서로 다른 이름을 가진다
  • 한 속성의 값은 모두 같은 도메인 값을 가진다
  • 속성의 순서는 상관없다, 달라도 같은 릴레이션 스크마
  • 릴레이션 내의 중복된 튜플은 허용하지 않는다
  • 튜플의 순서는 상관없다, 달라도 같은 릴레이션
• 제약조건 Constraints
  • 각 릴레이션에 저장된 데이터 값이 가져야 하는 제약
  • Like 나이 > 0
• 관계연산
  • 릴레이션을 다루는 연산 규칙
  • I.E. 주문, 고객 릴레이션을 조작하여 특정 고객의 주문 내역 검색

• @ 관계대수

• 관계 데이터 모델
  • 데이터를 2차원 테이블 형태 = 릴레이션으로 표현
  • 릴레이션에 대한 제약조건, 관계 연산을 위한 관계대수 Relation Algebra 정의
    • 릴레이션 생성, 관리, 제약조건 표현, 데이터 추출 연산 모두 SQL로

Key

---

• Key
  • 무엇인가를 유일하게 식별
  • 특정 튜플 식별 시 사용하는 속성, 속성 집합
  • 키가 되는 속성 (혹은 속성의 집합)은 반드시 값이 달라서 튜플을 구분할 수 있어야
    • 릴레이션 중복된 튜플 허용하지 않기 때문에 속성들 중 하나 이상은 값이 달라야
  • 릴레이션 간의 관계를 맺을 때도 사용
• Super Key
  • 튜플을 유일하게 식별할 수 있는 하나의 속성, 속성 집합
• Composite Key, 복합키 = 속성 집합 Key
  • Like (주민번호, 이름)
    • Super Key가 아닌 속성이 포함되어, Super Key가 될 수 있다

이때,
키를 구성하는 속성이 많으면
관계 표현이 복잡해짐, 사용하기 불편

• Candidate Key 후보키
  • 튜플을 유일하게 식별할 수 있는 속성의 최소 집합

(주민번호, 이름) VS 주민번호

• PK, Primary Key 기본키
  • 여러 후보키 중 하나를 선정하여 대표로 삼는 키
• PK 제약 조건
  • 릴레이션 내 튜플을 식별할 수 있는 고유한 값을 가져야
  • NULL 값 X
  • 키 값의 변동이 일어나지 않아야
  • 최대한 적은 수의 속성을 가진 것이라야
  • 향후 키를 사용하는 데 있어서 문제 발생 소지야 없어야
    • Like 주민번호, 개인정보 이슈

릴레이션 스키마를 표현할 때, PK는 밑줄을 그어 표시

• Surrogate Key 대리키, Artificial Key 인조키
  • 일련번호 같은 가상의 속성
  • 왜 Why?
    • PK가 보안을 요구 or 여러 개의 속성으로 구성되어 복잡 or 마땅한 PK가 없음
• Alternate Key 대체키
  • PK가 아닌 후보키
• FK, Foreign Key 외래키
  • 다른 릴레이션의 기본키를 참조하는 속성
• FK 제약 조건
  • 릴레이션 간의 관계를 표현
  • 다른 릴레이션의 PK를 참조하는 속성
  • 참고하고(FK) 참조되는(PK) 양쪽 릴레이션의 도메인은 동일
  • 참조되는(PK) 값이 변경되면 참조하는(FK) 값도 변경
  • NULL 값과 중복 값 등이 허용
  • 자기 자신의 PK를 참조하는 FK도 가능
  • FK가 기본키의 일부가 될 수 있음
• Super Key
  • Candidate Key
    • Primary Key
    • Alternate Key
  • Some Super Key…

무결성 제약조건

---

• 왜 Why
  • 데이터는 결함이 없고, 질의에 대해 신뢰성 있는 답을 제공해야
  • 데이터 신뢰도 유지
    • 일관성 유지, 중복 제거 등

So,
데이터 무결성 Integrity 유지되려면
데이터 삽입, 삭제, 수정 시 제약조건이 따름

일일이 할 수 있지만,
DBMS가 처리해준다면

• @ 무결성 제약조건
  • 데이터 무결성 Data Integrity
  • DB에 저장된 데이터의 완전성, 일관성, 정확성 지키는 것
  • 원본 데이터의 변경/파괴 없이 보존되는 특성을 내포
  • ALCOA
    • Attributable 완전하고 일관되며 정확한 데이터는 출처가 있어야 하며
    • Legible 읽을 수 있고
    • Contemporaneously Recorded 동시에 기록되어야 하며
    • Original or a True copy 원본 또는 진정한 사본이여야 하며
    • Accurate 정확해야 함
• 도메인 무결성 제약조건, Domain Integrity Constraint
  • = 도메인 제약, Domain Constraint
  • 릴레이션 내의 튜플들이 각 속성의 도메인에 지정된 값만을 가져야 한다는 조건
  • SQL 문에서 데이터 형식 Type, 널 Null/NotNull, 기본값 Default, 체크 Check 등을 사용하여 지정
• 개체 무결성 제약조건, Entity Integrity Constraint
  • = 기본키 제약, Primary Key Constraint
  • 기본키는 NULL 값을 가져서는 안되며 릴레이션 내에 오직 하나의 값만 존재해야 한다는 조건
• 참조 무결성 제약조건, Referential Integrity Constraint
  • = 외래키 제약, Foreign Key Constraint
  • 릴레이션 간의 참조 관계를 선언하는 제약조건
    • 참조되는 Referred 릴레이션 : Parent
    • 참조하는 Refer 릴레이션 : Child
  • 자식 외래 키는 부모 기본키와 도메인이 동일해야 함
  • 자식의 값이 변경될 때 부모의 제약을 받는다는 것
• UNIQUE 제약조건 (유일성, 고유성 제약조건)
  • 속성 모든 값들에 중복 X
• 사용자 정의 무결성
  • 트리거 (Event) 및 저장 프로시저 (Call) 를 통해 구현
  • 사용자 정의 제약 조건
    • I.E. 직원의 ID가 항상 AfterAcademy와 같은 특정 문자를 시작하고 그 뒤에 숫자가 와야 한다

---

릴레이션은 데이터 변경이 일어날 때 제약조건에 위배될 수 있음
→ 제약조건 준수여부는 데이터 변경 시 마다 확인

• 개체 무결성 제약조건 수행
  • 삽입 : PK 값이 중복되면, NULL이면 금지
  • 수정 : PK 값이 중복되면, NULL이면 금지
  • 삭제 : 즉시 수행 (참조 중이 아니라면)
• 참조 무결성 제약조건 수행
  • 삽입
    1. 개체 무결성 제약조건 확인
    2. FK가 부모 릴레이션에 존재하는 PK로 존재하는지 확인
       • FK가 NULL이라면 NULL 허용 확인
  • 삭제
    • 자식 릴레이션 : 즉시 수행
    • 부모 릴레이션
      • 참조하고 있는 릴레이션이 있는지 확인
      • 만약 존재한다면 (옵션)
        • RESTRICTED : 즉시 작업을 중지
        • CASCADE : 자식 릴레이션의 관련 튜플을 삭제
        • DEFAULT : 초기에 설정된 어떤 값으로 설정
        • NULL : NULL 값으로 설정
  • 수정
    • 삭제와 삽입 명령 연속 수행됨
    • 부모 릴레이션의 수정이 일어날 경우
      • 삭제 옵션에 따라 처리된 후 문제가 없으면 다시 삽입 제약조건에 따라 처리됨

관계대수

---

릴레이션에서 데이터를 추출하는 데 사용하는 언어

• 관계연산
  • 릴레이션에서 데이터 추출
  • 관계대수, 관계해석 언어를 통해

관계대수 : 어떤 데이터를 어떻게 찾는지에 대한 처리절차를 명시하는 절차적인 언어
관계해석 : 어떤 데이터를 찾는지만 명시하는 비절차적/선언적인 언어
=> Relationally complete 실제 동일한 표현 능력을 가지고 있음

• 관계대수, Relational Algebra (선술적 계산)
  • 질의하는 방법을 기술하는 절차적 언어
  • 하나 이상의 릴레이션을, 결과 릴레이션이 나오기 까지의 처리 연산의 집합

대수 : 수를 대신, 수를 대신하여 문자를 사용하는 방법
대수학 : 방정식을 푸는 방법을 연구하는 학문

SQL 언어는 관계해석을 기반으로 하지만,
(관계대수 개념 역시 혼합되어 있음)

DBMS 내부에서는 관계대수에 기반을 둔 연산을 수행하여
최종 결과 집합을 반환

• 관계의 수학적 의미
  • I.E. A = { 2, 4 }, B = { 1, 3, 5 }
  • A X B, 두 집합의 카티전 프로덕트
    • = A 원소와 B 원소의 순서쌍 집합
    • = { (2, 1), (2, 3), (2, 5), (4, 1), (4, 3), (4, 5) }
  • 릴레이션 R
    • = 카타전 프로덕트의 부분 집합
    • R1 = { (2, 1), (4, 1) }
    • R2 = { (2, 1), (2, 3), (2, 5) }
    • R3 = { (2, 3), (2, 5), (4, 3), (4, 5) }
  • 원소 개수가 n인 집합의 부분집합의 개수 : 2^n

  • A X B의 부분집합의 개수 : 2^(

    A

    X

    B

    )

  • 도메인 Domain
    • = 카타전 프로덕트의 기초 집합이 각각이 가질 수 있는 값의 범위
    • 집합 A의 도메인 = { 2, 4 }
    • 집합 B의 도메인 = { 1, 3, 5 }
  • 릴레이션도 집합
    • 집합 연산
      • 합집합 ⋂, 교집합 ⋃, 카티전 프로덕트 X
      • R1 ⋃ R2 = { (2, 1), (4, 1), (2, 3), (2, 5) }
      • R1 ⋂ R2 = { (2, 1) }

S	: 집합 S의 원소 수

카티전 프로덕트 : 모든 경우의 수
릴레이션 : 하나의 경우

• 관계대수 연산자
  • 순수 관계 연산, Relational Operations
    • 관계 데이터 모델을 위해 고안
    • 셀렉션 Selection, 프로젝션 Projection, 조인 Join, 디비전 Division, 개명 Rename
  • 일반 집합 연산, Set Operations
    • 합집합 Union, 차집합 Difference, 교집합 Intersection, 카티전 프로덕트 Cartesian Product

단항 연산자 Unary Operator
이항 연산자 Binary Operator
유도 연산자 : 기본 연산자로부터 유도

• 관계대수식 Relational Algebra Expression
  • 관계대수 연산을 수행하기 위한 식
  • 단항 연산자 : 연산자_<조건> 릴레이션
  • 이항 연산자 : 릴레이션1 연산자_<조건> 릴레이션2</sub>
  • 결과는 릴레이션, 즉 중복된 튜플은 하나만 표시

Selection, Projection
관계대수에서 가장 기본적인 연산
하나의 R을 대상으로 하는 단항 연산자

• Selection
  • R의 Tuple 추출
  • 결과 R 차수 = 대상 R
  • 결과 R 카디널리티 <= 대상 R
  • σ _Predicate (R), σ _{가격 <= 8000} (도서)
  • Predicate, 속성 = 상수값/속성 형태
  • 여러 개의 Predicate, ∧(and) ∨(or) ￢(not)
• Projection
  • R의 속성 추출
  • 결과 R 차수 <= 대상 R
  • 결과 R 카디날리티 = 대상 R
  • π _{속성 리스트} (R), π _{이름, 주소, 핸드폰} (고객)

합병가능 Union Compatible
두 피연산자 릴레이션은 서로 같은 속성 수와 순서, 도메인

• 집합 연산

• ⋃ Union
  • 두 R 합하여 하나의 R로
  • 두 R은 서로 같은 속성 수와 순서, 도메인
  • 속성 이름은 첫 번째 R의 것을
• ⋂ Intersection
  • 두 R이 공통으로 가지고 있는 Tuple 반환
  • 두 R은 서로 같은 속성 수와 순서, 도메인
  • 기본 연산자로 정의 가능한 유도된 연산자, R⋂S = R−(R−S)
• − Set Difference
  • 첫 R에는 속하고, 두 번째 R에는 속하지 않는 Tuple 반환
  • 두 R은 서로 같은 속성 수와 순서, 도메인
• ⨉ Cartesian Product
  • 수평적 연산 (VS 다른 연산자들, 수직적 연산)
  • 두 R을 연결시켜 하나의 R로
  • 첫 R의 오른쪽에 두 번째 R의 모든 Tuple을 순서대로 배열
  • 속성과 도메인이 동일하지 않아도 됨
  • 결과 R 차수 = 두 R 차수 합
  • 카디날리티 = 두 R 카디널리티 곱
  • 속성 이름은 그대로
    • 충돌 시 ‘릴레이션 이름.속성 이름’ or 순서(위치) 사용
  • 단독으로 사용하면 의미 없는 결과, 보통 Selection, Projection과 함께
• Join
  • 두 R의 공통 속성을 기준으로 속성 값이 같은 Tuple을 수평적으로 결합
  • 즉, 두 R을 ⨉ 한 후 σ (속성 값 같은 지) 한 것
  • 유도 연산자, R⨝_cS = δ_c(R⨉S)
  • R과 S는 동일 도메인, c = Join 조건
• 기본 조인 연산

• 확장된 조인 연산

• 기본 조인 연산
  • Theta 세타조인, 속성 값 비교, ⨝
    • Inner 내부조인/Equal 동등조인, 조건 =
      • Natural 자연조인, 중복 속성 제거, ⨝_N
• 확장된 조인 연산 (자연조인 Base)
  • Semi 세미조인, 자연조인 후 한 쪽 R의 Tuple만 반환
    • ⨝ 기호에 좌우 닫힘 유무
  • Outer 외부조인, 자연조인 실패 값을 NULL로 채워 반환
    • 기준 R 위치에 따라, Left 왼쪽, Right 오른쪽, Full 완전 외부조인
    • ⨝ 기호에 좌우 삐침 유무
• Division %
  • R 속성 값의 집합으로 연산
  • 오른쪽 R의 모든 Tuple을 속성으로 가지는 왼쪽 R의 Tuple들을 반환

@ 114p

Select π (Projection)
From R ()
Where δ (Selection)

SQL

• QBE Query by Example?

• 관계 데이터 연산

  • 연산 Operation과 데이터 언어 Data Language
    • 연산 : 명령 수행, 시스템 입장
    • 데이터 언어 : 사용자 입장
  • 관계 데이터 언어 Relational Data Language
    • 정형어 Formal Language, a Set of Strings of Symbols
      • 관계 대수 Relational Algebra
        • 절차 언어 : How, What
      • 관계 해석 Relational Calculus
        • 비 절차 언어 : What
        • Two Calculi
          • 튜플 관계 해석 Tuple Relational Calculus
          • 도메인 관계 해석 Domain Relational Calulus
  • 관계 해석과 관계 대수는 표현과 기능면에서 동등
    • Relationally Complete

, Relational Calculus (술어 해석)

• 관계 해석 Example
  • 튜플 관계 해석 Tuple Relational Calculus

    • {t	EMPLOYEE(t) and t.SALARY > 50000}

    • {t

      P(t)}

  • 도메인 관계 해석

    • {uv	(∃q} (∃r) (∃s) (EmPLOYEE(qrstuvwxyz) and q = ‘John’ and r = ‘B) and s = ‘Smith’)}

    • ∃, 임의의
• QBE Example
  • DBSs 들로 구현된 Query Method
  • Graphical Query Language
  • 에제 테이블을 만들어 Query 작성
  • 명령 P. = 인쇄

---

데이터 모델링

~

---

• 데이터 모델링의 개념
  • Physical Data Model: Blueprint and Data Diagram at the Physical Level

~

• DB 생명주기
  • DB Life Cycle
  • DB의 생성과 운영과 관련된 특징
    • Requirements Analysis 요구사항 수집 및 분석
      • 사용자들의 요구사항을 듣고 분석하여 DB 구축의 범위를 정함
    • Design 설계
      • 분석된 요구사항을 기초
      • 주요 개념과 업무 프로세스 등을 식별 (개념적 설계)
      • 사용하는 DBMS의 종류에 맞게 변화 (논리적 설계)
      • DB 스키마를 도출 (물리적 설계)
    • Implementation 구현
      • 설계 단계에서 생성한 스키마를 실제 DBMS에 적용
      • 테이블 및 관련 객체 (뷰, 인덱스 등)를 생성
      • DBMS의 CLI 혹은 GUI
    • Operation 운영
      • 구현된 데이터베이스를 기반으로 SW를 구축하여 서비스를 제공
    • Maintenance 유지보수 (Monitoring Modification 감시 및 개선)
      • DB 운영에 따른 시스템의 문제를 관찰
      • DB 자체의 문제점을 파악하여 개선
• 데이터 모델링 과정
  • 요구사항 수집 및 분석
    • 현실세계의 대상 및 사용자의 요구 등을 정리 및 분석
      • 사용자 식별
      • DB 용도 식별
      • 사용자 요구 사항 수집 및 명세
    • 설계
      • 개념적 모델링
        • 중요 개념을 구분
          • 핵심 Entity(독집개체) 도출
          • ERD 작성
      • 논리적 모델링
        • 각 개념을 구체화
          • ERD-RDB 모델 시상
          • 상세 속성 정의
          • 정규화 등
      • 물리적 모델링
        • DB 생성 계획에 따라 개체, 인덱스 등을 생성
          • DB 개체 정의
          • 테이블 및 인덱스 등 설계
    • DB 구현
• 요구사항 수집 및 분석
  • 실제 문서를 수집하고 분석함
  • 담당자와의 인터뷰나 설문조사를 통해 요구사항을 직접 수렴함
  • 비슷한 업무를 처리하는 기존의 DB를 분석함
  • 각 업무와 연관된 모든 부분을 살펴봄
• 개념적 모델링 Conceptual Modeling
  • 요구사항을 수집하고 분석한 결과를 토대로 업무의 핵심적인 개념을 구분하고 전체적인 뼈대를 만드는 과정
  • 개체(Entity)를 추출하고 각 개체들 간의 관계를 정의
  • ERD Entity Relationship Diagram을 만드는 과정까지를 말함
  • I.E.
    • 도서(도서이름,출판사,도서단가) → 주문(주문일자) ← 고객(고객이름,주소, 전화번호)
    • Entity는 명사, Relationship은 동사 느낌
• 논리적 모델링 Logical Modeling
  • 개념적 모델링에서 만든 ERD을 사용하려는 DBMS에 맞게 사상(매핑, Mapping)하여 실제 DB로 구현하기 위한 모델을 만드는 과정
  • To establish the structure af data elements and the relationships among them.
  • 논리적 모델링 과정
    • 개념 모델링에서 추출하지 않았던 상세 속성들 모두 추출
    • 정규화 수행
    • 데이터 표준화 수행
    • I.E.
      • 도서(@도서번호, 도서이름,출판사,도서단가) → 주문(@주문번호, 고객번호(FK), 도서번호(FK), 주문일자) ← 고객(@고객번호,고객이름,주소, 전화번호)

---

@0406

• 물리적 모델링 Physical Modeling
  • DBMS의 특성에 맞게 저장 구조를 정의
  • 논리적 모델을 실제 컴퓨터의 저장 장치에 저장하기 위한 물리적 구조를 정의하고 구현하는 과정
  • DB가 최적의 성능을 낼 수 있음
  • 트랜잭션, 저장 공간 설계 측면에서 고려할 사항
    • 응답시간을 최소화
    • 얼마나 많은 트랜잭션을 동시에 발생시킬 수 있는지 검토
    • 데이터가 저장딜 공간을 효율적으로 배치
  • I.E. CREATE TABLE Book { bookid INT PRIMARY KEY, … }
• ER Entity Relationship 모델
  • 세상의 사물을 개체Entity화와 개체 간의 관계Relationship로 표현함
  • ERM Entity Relationship Model (ER model)
  • Composed of entity types
  • Specifies relationships that can exist between instances of those entity types

  • Design by Peter Chen and published in a 1976 paper

  • Entity 개체
    • 독집적인 의미를 지니고 있는 유무형의
    • 개체의 특성을 나타내는 Attribute 속성에 의해 식별
    • 개체끼리 서로 관계를 가짐
    • Chen notation, Crow’s foot notation
  • 개체, 관계, 역할 (관계에서 개체가 하는 기능, I.E. 결혼이라는 관계에서의 역할 = 남편, 아내)
  • ER 다이어그램
    • ER 모델은 개체와 개체 간의 관계를 표준화된 그림으로 나타냄
• 개체와 개체 타입
  • 개체 Entity
    • 사람, 사물, 장소, 개념, 사건과 같이 유-무형의 정보를 가지고 있는 독립적인 실체
  • 개체 유형 Entity Type
    • Collection of entity having common attribute (Intention:내연)
  • 개체 집합 Entity Set
    • A set of entities of some entity type
    • Extension of an entity type (외연)
• 개체 타입의 ER 다이어그램 표현
  • 직사각형으로 나타냄
  • 개체 타입의 유형
    • 강한 개체 Strong Entity
      • 다른 개체의 도움 없이 독자적으로 존재할 수 있는 개체, I.E. 직원
    • 약한 개체 weak Entity
      • 독자적으로는 존재할 수 없는 반드시 상위 개체 타입을 가짐, I.E. 부양가족
• 속성
  • 속성 Attribute
    • 개체가 가진 성질
    • I.E. 개체타입 : 도서, 속성 : { 도서이름, 출판사, 도서단가 }
  • 속성의 ER 다이어그램 표현
    • 속성은 기본적으로 타원으로 표현
    • 개체 타입을 나타내는 직사각형과 실선으로 연결됨
    • 속성의 이름은 타원의 중앙에 표기
    • 속서이 개체를 유일하게 식별할 수 있는 키일 경우 속성 이름에 밑줄을 그음, I.E. 도서이름
• 속성의 유형
• I.E. 도서
  • 도서 번호
    • 속성
    • 일반적 송성
  • 도서 이름
    • 키 Key 속성
    • 개체를 유일하게 식별하는 속성
    • 이름에 밑줄로 표시
  • 부양 가족
    • 약한개체 식별자
    • 키 대신 식별자 Discriminator (or Partial Key)
    • 식별자 표시는 점선
  • 취미
    • 다중값 속성
    • 취미는 여러 개를 가질 수 있음
    • 이중 타원
  • 나이
    • 유도 속성
    • 출생연도로 나이 유도 가능
    • 점선 타원
  • 주소 - { 시, 동, 번지 }
    • 복합 속성
    • 여러 속성으로 구성
    • 큰 원 아래 작은 타원
• 관계와 관계 타입
  • 관계 Relationship
    • 개체 사이의 연관성을 나타내는 개념
  • 관계 타입 Relationship Type
    • 개체 타입과 개체 타입 간의 연결 가능한 관계를 정의
  • 관계 집합 Relationship Set
    • 관계로 연결된 집합을 의미

---

~

@0417

• ER 모델 => 관계 데이터 모델 사상
  • 완성된 ER 모델 => 실제 데이터베이스 구축을 위해
    • 논리적 모델링 단계 수행
    • 이 단계에서 @사상(mapping)이 이루어짐
    • @그림을 변환하는 과정
    • @그림 => 도서(도서번호, 도서이름, 출판사, 도서단가)

• 사상 알고리즘

• 1-2단계 - 개체 타입
  • 1단계 강한(정규) 개체 타입
    • 정규 개체 타입 E의 경우 대응하는 릴레이션 R을 생성함
  • 2단계 약한 개체 타입
    • 약한 개체 타입에서 생성할 릴레이션
    • 자신의 기본키 구성
      • 자신의 키와 함께 강한 개체 타입의 키를 외래키로 사상
  • @강한 개체 타입(사원) - 관계(부양) - 약한 개체 타입(가족)
  • @가족 타입이 사원 타입에 종속된 약한 타입이므로, 사원 개체 타입의 키인 사번 속성을 외래키 FK로 포함
• 3-6단계 - 관계 타입
  • 표현 방법 (4가지)
    • 1 오른쪽 개체 타입 E2를 기준으로 관계 R 표현
      • E1(KA1, A2) E2(KA2, A4, KA1)
    • 2 왼쪽 “
      • E1(KA1, A2, KA2) E2(KA2, A4)
    • 3 단일 릴레이션 ER로 모두 통합하여 관계 R 표현
      • ER(KA1, A2, KA2, A4)
    • 4 개체 타입 E1, E2와 관계 타입 R을 모두 독립된 릴레이션으로 표현
      • E1(KA1, A1) R(KA1, KA2) E2(KA2, A4)
  • 3단계 이진 1:1 관계 타입
    • 모든 표형 방법으로 사상 가능
    • 개체가 가진 정보 유형에 따라 판단
    • @사원 - 사용 - 컴퓨터
  • 4단계 이진 1:N 관계 타입
    • N의 위치에 따라 1, 2 유형으로 사상됨
    • @학과 - 소속 - 학생
  • 5단계 이진 M:N 관계 타입
    • 4 유형으로 사상
    • @ 교수 - 수업 - 과목
    • @ 수업 릴레이션은 N:M 관계를 표현하는 @교차 릴레이션
  • 6단계 N진 관계 타입
    • -ER 모델의 차수가 3 이상인 다진 관계 타입의 경우
    • 4 유형으로 사상
    • @ 수강 - 학생 N, 강좌 M, 강의실 1
    • @ 차수가 3 이상인 관계 타입은 교차 릴레이션으로 표현
    • @ 생성되는 릴레이션 R의 키는 각 개체 타입의 기본키를 모은 복합키를 사용
• 7단계 - 속성
  • 7단계 다중값 속성
    • 속성의 개수를 알 수 없으면 1 유형,
      • R(KA, B) RC(KA, C)
    • 속성의 개수가 제한적으로 정해지면 2 유형
      • R(KA, B, C1, C2, C3)
    • @ 학생 { 학번, 이름, 취미 }
    • @ 학생(학번, 이름) 취미(학번, 취미이름)
    • @ 한 학생이 게임, 등산, 스키, 노래부르기 등 여러 취미가 있을 수 있으므로 독립적인 릴레이션을 만들어 저장

---

• 관계 데이터 모델

• @ SET A = { a, b, c }
• @ BAG A = { a, b, b, b, c }
• 릴레이션, 두 개의 집합에 대응되는 것을 뽑아 놓은 것

---

• MariaDB 오픈소스 DB
• 윤곽 자체가 MySQL랑 거의 같음

• DB 연결할 때 인스턴스 자체 딘펜던시를 MySQL로 잡고 MariaDB에 접속을 할라고 해도 접속이 되거든요

• 많은 Form이 복사된 상태기 때문에, 이제 MySQL 쓰는 것과 크게 다른 게 없다

• MySQL Workbench(GUI) 제공하는데

• MariaDB는 그게 없어서 HeidiSQL을 따로 설치

• DB에서 기본적인 스키마를 짜놓고, 그걸 가져다가 쓰거든요