SQLD(SQL-Developer) (6)

💙 식별자 구분(대체 여부에 따른)

1️⃣ 본질식별자

- 업무에 의해 만들어지는 식별자(꼭 필요한 식별자)

 

2️⃣ 인조식별자

- 인위적으로 만들어지는 식별자(꼭 필요하지 않지만 관리의 편의성 등의 이유로 인위적으로 만들어지는 식별자)

- 본질식별자가 복잡한 구성을 가질때 인위적으로 생성

- 주로 각 행을 구분하기 위한 기본키로 사용되며 자동으로 증가하는 일련번호 같은 형태임

 

예제) 주문과 주문상세에 대한 엔터티 설계 과정을 예를 들어보자.

주문이 들어오면 주문 엔터티에는 (주문번호 + 고객번호)를 저장, 이 때 PK는 주문번호이다.

주문상세에는 각 주문별로 어떤 상품이, 언제, 몇 개 주문됐는지 등을 기록한다.

 

※ 주문상세 테이블 설계 시 다음과 같은 식별자를 고려할 수 있다.

 

1. PK : 주문번호 + 상품번호로 설계

  - 주문을 하면 주문번호와 상품번호가 필요하므로 본질식별자(주문번호 + 상품번호)가 된다

  - 하지만 PK가 주문번호 + 상품번호이면 하나의 주문번호로 같은 상품의 주문 결과를 저장할 수 없게 된다.

👉🏻 실제로 쇼핑을 하다보면 동일한 장바구니에 A 상품을 5개 주문했는데, 뒤에 또 다시 A 상품을 3개 추가로 주문하기도 함.

 

2. PK : 주문번호 + 주문순번(주문순번이라는 컬럼을 생성)

  - 하나의 주문에 여러 상품에 대한 주문 결과 저장 가능 -> 주문순번으로 인해 구분함

👉🏻 매 주문마다 동일한 상품 주문 시 주문순번을 정하기 위해 상품의 주문 횟수를 세야 한다는 점이 매우 불편! 

즉, 사과를 총 3번 구매 하였으니 주문순번은 1,2,3, 순서대로 입력돼야 함

 

3. PK : 주문상세번호(인조식별자 생성)

  - 주문상세번호로 각 주문이력을 구분하기 때문에 같은 주문의 같은 상품이력이 저장될 수 있음

  - 주문상세번호만이 주식별자이므로 나머지 정보들이 불필요하게 중복 저장될 위험 바랫ㅇ

  - 실제 업무와 상관없는 주문상세번호를 주식별자로 생성하면 쓸모없는 index가 생성됨(PK 생성 시 자동 unique index 생성)

 

※ 따라서 인조식별자는 다음의 단점을 가지게 된다.

1. 중복 데이터 발생 가능성 -> 데이터 품질 저하

2. 불필요한 인덱스 생성 -> 저장공간 낭비 및 DML 성능 저하

 

** 인덱스는 원래 조회 성능을 향상시키기 위한 객체이며, 인덱스는 DML(INSERT/UPDATE/DELETE)시 INDEX SPLLIT 현상(데이터가 쪼개진다)으로 인해 성능이 저하된다.

 

<관계형 데이터베이스 개요>

💙 데이터베이스(Database)와 DBMS(Database Management System)

- DBMS는 소프트웨어, 이 소프트웨어가 관리하는 데이터의 집합이 데이터베이스.

- 데이터베이스 : 데이터의 집합. 꼭 형식을 갖추지 않아도 엑셀 파일을 모아 둔다면 그것 또한 데이터베이스임

- DBMS : 데이터를 효과적으로 관리하기 위한 시스템

개인이 파일을 여러 개 묶어서 폴더에 보관하면 데이터를 찾고 관리하는데 많은 비용이 발생. 이를 보다 시스템적으로 작동하게 만든 시스템을 DBMS라고 한다(ORACLE, MYSQL 등)

 

💙 관계형 데이터베이스 구성 요소

- 계정 : 데이터의 접근 제한을 위한 여러 업무별/시스템별 계정이 존재

- 테이블 : DBMS의 DB 안에서 데이터가 저장되는 형식

- 스키마 : 테이블이 어떠한 구성으로 되어있는지, 어떠한 정보를 가지고 있는지에 대한 기본적인 구조를 정의

 

💙 테이블

1️⃣ 정의

- 엑셀에서의 워크시트처럼 행(로우)와 열(컬럼)을 갖는 2차원 구조로 구성, 데이터를 입력하여 저장하는 최소 단위

- 컬럼은 속성이라고도 부름(모델링 단계마다 부르는 용어가 다름)

 

2️⃣ 특징(⭐중요함)

- 하나의 테이블은 반드시 하나의 유저(계정) 소유여야 함

- 테이블간 관계는 일대일(1:1), 일대다(1:N), 다대다(N:N)의 관계를 가질 수 있음

 

- 테이블명은 중복될 수 없지만, 소유자가 다른 경우 같은 이름으로 생성 가능

ex) SCOTT 소유의 EMP 테이블 존재, HR 소유의 EMP 테이블 생성 가능(같은 계정 내 동일한 객체명 생성 불가)

 

- 테이블은 행 단위로 데이터가 입력, 삭제되며 수정은 값의 단위로 가능

ex) 사원테이블에 새로운 사원 정보를 사원번호, 사원이름 등의 테이블 내 모든 컬럼의 값을 동시에 전달하여 입력, 삭제 시에는 해당 사원의 모든 정보가 삭제됨(수정 시에는 특정 직원의 급여만 수정 가능)

 

※ 객체 : DBMS 에서의 객체는 생성하고 변경할 수 있는 하나의 관리 대상

 

 

💙 SQL(Structured Query Language)

- 관계형 데이터베이스에서 데이터 조회 및 조작, DBMS 시스템 관리 기능을 명령하는 언어

- 데이터 정의(DDL), 데이터 조작(DML), 데이터 제어 언어(DCL)등으로 구분

- SQL 문법은 대,소문자를 구분하지 X

 

💙 관계형 데이터베이스 특징

- 데이터의 분류, 정렬, 탐색 속도가 빠름

- 신뢰성이 높고, 데이터의 무결성 보장

- 기존의 작성된 스키마를 수정하기 어려움

- 데이터베이스의 부하를 분석하는 것이 어려움

 

💙 데이터 무결성(integrity)

- 데이터의 정확성과 일관성을 유지하고, 데이터에 결손과 부정합이 없음을 보증하는 것

- 데이터베이스에 저장된 값과 그것이 표현하는 현실의 비즈니스 모델의 값이 일치하는 정확성을 의미함

- 데이터 무결성을 유지하는 것이 데이터베이스 관리시스템에 중요한 기능

 

💙 데이터 무결성 종류

1️⃣ 개체 무결성 : 테이블의 기본키를 구성하는 컬럼(속성)은 NULL 값이나 중복값을 가질 수 없음

2️⃣ 참조 무결성 : 외래키 값은 NULL이거나 참조 테이블의 기본키 값과 동일해야 한다. (외래키란 참조 테이블의 기본키에 정의된 데이터만 허용되는 구조이므로)

3️⃣ 도메인 무결성 : 주어진 속성 값이 정의된 도메인에 속한 값 이어야 함

4️⃣ NULL 무결성 : 특정 속성에 대해 NULL을 허용하지 않는 특징

5️⃣ 고유 무결성 : 특정 속성에 대해, 값이 중복되지 않는 특징

6️⃣ 키 무결성 : 하나의 릴레이션(관계)에는 적어도 하나의 키가 존재해야 함 (테이블이 서로 관계를 가질 경우 반드시 하나 이상의 조인키를 가짐)

 

※ 도메인 : 각 컬럼(속성이 갖는 범위

※ 릴레이션 : 테이블간 관계를 말함

※ 튜플 : 하나의 행을 의미함

※ 키 : 식별자

 

💙 ERD(Entity Relationship Diagram)

- ERD란 테이블 간 서로의 상관 관계를 그림으로 표현한 것

- ERD의 구성요소에는 엔터티(Entity), 관계(Relationship), 속성(Attribute)가 있다.

  -> 현실 세계의 데이터는 이 3가지의 구성으로 모두 표현 가능