인덱스란?

• 색인 : 쉽게 찾아볼 수 있도록 일정한 순서에 따라 놓은 목록
• 원하는 값을 빠르게 찾을 수 있음
• where 절을 통해서 검색할 수 있어야 인덱스가 사용됨
• 데이터베이스 테이블에 대한 검색 성능을 향상시키는 자료 구조이며, where 절 등을 통해서 활용됨

인덱스를 적용하지 않는다면?

• 100만건 이상의 데이터에서 이메일이 yn324@naver.com인 회원을 조회할 때 느리다
• 전체 데이터에서 순차적으로 확인하기 때문에!
• 데이터가 기준없이 저장된 상태이기 때문에 데이터가 특정 기준으로 정렬되어 있다면 검색을 빠르게 할 수 있음

인덱스 특징

• 인덱스는 항상 최신의 정렬상태를 유지함
• 인덱스도 하나의 데이터베이스 객체
• 데이터베이스 크기의 약 10% 정도의 저장공간 필요

인덱스 알고리즘

• 페이지 : 데이터가 저장되는 단위 (16 kbyte)

인덱스 알고리즘 : Full Table Scan

• 총 3개의 페이지를 거치고 12번 검색함

특징

• 순차적으로 접근
• 접근 비용 감소

사용하는 경우

• 적용 가능한 인덱스가 없는 경우
• 인덱스 처리 범위가 넓은 경우
• 크기가 작은 테이블에 엑세스하는 경우

참고 자료구조 : 이진 탐색 트리

• 모든 노드의 왼쪽 서브트리는 해당 노드의 값보다 작은 값들만 가지고, 모든 노드의 오른쪽 서브 트리는 해당 노드의 값보다 큰 값들만 가짐
• 20을 기준으로 봤을 때, 20보다 왼쪽 서브트리는 20보다 작고, 20보다 오른쪽 서브트리는 20보다 큼
• 자녀노드는 최대 2개까지 가질 수 있음

인덱스 알고리즘 : B-tree

• 자녀 노드의 최대 개수를 늘리기 위해서 부모 노드에 key를 하나 이상 저장함
• 부모 노드의 key들을 오름차순으로 정렬함
• 정렬된 순서에 따라 자녀 노드들의 key 값의 범위가 결정됨
• BST를 일반화한 tree

파라미터

• internal 노드의 key 수가 x개라면 자녀 노드의 수는 언제나 x+1개
• 모든 leaf 노드들은 같은 레벨에 있음 ⇒ 어떤 경우에도 시간복잡도가 O(logN)임

실제 인덱스에서의 B-Tree

• 총 2개의 페이지를 거치고 7번 검색

⇒ 이를 통해 select의 성능이 향상됨

insert

• 페이지 분할이 발생하여 성능이 느려지게 됨
• 페이지 분할
  • 페이지에 새로운 데이터를 추가할 여유공간이 없어 페이지에 변화가 발생
  • DB가 느려지고 성능에 영향을 줌

delete

• 인덱스의 데이터를 실제로 지우지 않고 사용안함 표시를 함

update

• 가장 먼저 delete 수행 (기존 값 사용안함 표시)
• 그 다음 insert 수행 (변경된 값 삽입)

delete & update

• where절로 처리할 대상을 찾기 위한 조회 성능은 향상되지만,
• 사용하지 않는 인덱스가 적용되었다면 불필요한 처리량 증가
• 사용안함 표시로 페이지 낭비 및 인덱스 조각화 심해짐
• 인덱스 조각화 : 인덱스가 논리적으로 정렬되어 있지 않고, 물리적으로 비효율적으로 저장되어 있는 상태

결론

• select는 성능이 향상되지만 insert, delete, update는 페이지 분할과 사용안함 표시로 인덱스의 조각화가 심해져 성능이 저하됨

인덱스 종류

• pk를 걸면 자동으로 클러스터링 인덱스가 생김
  • 하나의 컬럼에 not null과 unique 제약조건을 같이 걸어도 걸림
• unique 제약조건을 걸면 자동으로 논 클러스터링 인덱스가 생김

클러스터링 인덱스

• 실제 데이터와 같은 무리의 인덱스
• 실제 데이터가 정렬된 사진

• 실제 데이터 자체가 정렬
• 테이블당 1개만 존재 가능
• 리프 페이지가 데이터 페이지
• 아래 제약조건 시 자동 생성
  • pk를 걸면 (우선순위 1위)
  • not null + unique

클러스터링 인덱스 적용

논 - 클러스터링 인덱스

• 실제 데이터와 다른 무리의 별도의 인덱스
• 실제 데이터 탐색에 도움을 주는 별도의 찾아보기 페이지

• 실제 데이터 페이지는 그대로
• 별로의 인덱스 페이지 생성 → 추가 공간 필요
• 테이블당 여러 개 존재
• 리프 페이지에 실제 데이터 페이지 주소를 담고 있음
• 아래 제약조건 시 자동 생성
  • unique 제약조건 적용시 자동 생성
  • 직접 index 생성시 논-클러스터링 인덱스 생성

논 - 클러스터링 인덱스 적용

• 이름에 인덱스 걸음
• 리프페이지에서 이름을 기준으로 정렬된 모습을 보임

클러스터링 + 논클러스터링을 동시에 적용했을 때

• 데이터가 추가되거나 삭제될 때마다 인덱스페이지의 주소가 바뀌면 비효율적이기 때문에
• 논 클러스터링 인덱스의 리프 페이지에 실제 데이터 페이지 주소가 아닌 클러스터링 인덱스가 적용된 컬럼의 실제 값을 가지고 있음

인덱스 적용 기준

• 카디널리티 : 테이블에서의 행의 갯수, 요소의 갯수
• 디그리 : 테이블에서의 열의 갯수
• 카디널리티(그룹 내 요소의 개수)가 높은 것, 중복수치가 낮은 것에 걸어야 함!
• where, join, order by 절에 자주 사용되는 컬럼
  • 인덱스는 추가 공간이 필요로 됨
  • 조건 절이 없다면 인덱스가 사용되지 않음
• insert, delete, update 가 자주 발생하지 않는 컬럼
• 규모가 작지 않은 테이블

출처

https://www.youtube.com/watch?v=bqkcoSm_rCs 

https://youtu.be/edpYzFgHbqs?si=LOEZHxbgX_-_myEa

json server

짧은 시간 내에 REST API 서버의 기본적인 기능 대부분을 구축해주는 라이브러리

HTTP 클라이언트 사용 : 웹 애플리케이션에서 HTTP 요청을 보내고 응답을 받을 수 있는 도구

REST API

• REST를 기반으로 만들어진 API
• REST
  • 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것
  • HTTP URI를 통해 자원(Resource)을 명시하고 HTTP Method를 통해 해당 자원(URI)에 대한 CRUD를 적용하는 것
  • 자원(Resource) : 웝페이지(html), binary data(그림파일, 소리파일 등), db data(json, html로 render된 data)

Create : 데이터 생성(POST)
Read : 데이터 조회(GET)
Update : 데이터 수정(PUT, PATCH)
Delete : 데이터 삭제(DELETE)

HTTP Method

GET

• 서버에게 resource를 보내달라고 요청
• 서버(혹은 DB)의 resource는 클라이언트로 전달만 될 뿐 변경되지 않음
• 웹 브라우저에 이미지 url을 입력하면 해당 그림 파일이 표시되는 것

POST

• 서버에게 resource를 보내면서 생성해 달라고 요청
• 회원가입을 하면 DB에 새로운 회원정보가 등록되는 것

PUT

• 서버에게 resource를 업데이트 하도록 요청
• resource가 없다면 새로운 resource를 생성해 달라고 요청
• 항상 모든 필드값을 가져와서 필드를 새로운 값으로 교체
• 회원정보를 수정하는 것

PATCH

• 서버에게 resource를 업데이트 하도록 요청
• 주어진 필드만 수정하여 부분 데이터를 업데이트

DELETE

• 서버에게 resource의 삭제 요청

정렬 (sort)

• DESC : 내림차순
• ASC : 오름차순

GET /memo?_sort=id&_order=DESC    //내림차순
GET /memo?_sort=id&_order=ASC     //오름차순

연산자 (Operators)

• gte: 크거나 같다
• lte: 작거나 같다
• ne: 일치하지 않는다

GET /memo?id_gte=10    
GET /memo?id_lte=10
GET /memo?id_ne=10

제한 (limit)

GET /memo?_limit=2

MySQL 데이터베이스 서버 생성, 스키마 생성

PERFROMMANCE

• 데이터 베이스의 성능상의 영향을 보여줌

Index 설정

• 데이터베이스 튜닝 : 데이터베이스의 성능을 향상시키고, SQL의 처리 시간을 줄이는 작업
• index는 1개만 설정 가능 → 정렬기준이므로
• PK에 AT걸려 있을 때 주로 사용
• 저장 공간을 활용하여 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조
• PK : index가 자동으로 생성됨
• PK가 아닌 다른 column에 대해서 index를 만들어 주는 작업

뷰 : 가상의 테이블

Stored procedure

• 일련의 쿼리를 마치 하나의 함수처럼 실행하기 위한 쿼리의 집합
• 특정 로직의 쿼리를 함수로 만들어 놓은 것

데이터베이스 설계 단계

1. 요구사항 수집 분석
   • 데이터베이스의 사용 용도 파악
   • 요구사항 명세서 작성
2. 개념 스키마 설계
   • 요구사항 명세서를 바탕으로 entity, relationship으로 분리하여 와 E-R 다이어그램 작성
   • 각각의 entity가 가지는 속성 도출
     • entity : 데이터베이스에 표현되어야 하는 객체
     • relationship : entity를 연결하는 entity간의 관련성
3. 논리 스키마 설계
   • 데이터를 어떻게 저장할 것인가
   • sql문을 이용하여 entity를 table로 만들고, 속성을 정의함
   • 테이블간의 관계는 FK로 정의
4. 물리 스키마 설계
   • 실제로 어떻게 저장하고 보관하고 관리할 것인가
   • 데이터베이스 튜닝 : 데이터베이스의 처리 속도를 향상시키고 응답 시간을 최소화하는 작업

Trigger

데이터 일관성을 유지하기 위해 INSERT, DELETE, UPDATE 같은 DML이 수행될 때, 데이터베이스에서 자동으로 동작하는 것 → 지울 때는 항상 키값으로 삭제

CREATE DEFINER=`root`@`localhost` TRIGGER `topic_backup_AFTER_DELETE` AFTER DELETE ON `topic_backup` FOR EACH ROW BEGIN
	INSERT INTO removed
		VALUES (OLD.id, OLD.title, now() );
END

DELETE FROM topic_backup WHERE title = 'C' ;
select * from removed;

데이터베이스 시스템의 구성 요소

1. 데이터베이스 서버
   • 데이터베이스에 대한 저장, 관리, 접근, 조작 등의 작업을 수행
   • 클라이언트로부터의 요청을 받아들여 해당 요청을 처리하고 결과를 반환
   • 데이터베이스 관리 시스템(DBMS)에 의해 구현
2. 데이터베이스 클라이언트
   • 데이터베이스 서버에 연결하여 데이터베이스와 상호 작용하는 소프트웨어나 인터페이스
   • 사용자 또는 응용 프로그램이 데이터베이스에 접속하여 데이터를 조회, 삽입, 수정, 삭제 등의 작업을 수행할 수 있도록 도움

MySQL Client

• MySQL Monitor - CLI기반
• MySQL Workbench - GUI기반

SQL 분류

1. DML(Data Manipulation Language)
   • 데이터 조작 언어
   • SELECT, INSERT, UPDATE, DELETE
2. DDL(Data Definition Language)
   • 데이터 정의 언어, 데이터베이스 개체를 생성, 삭제, 변경
   • CREATE, DROP, ALTER
3. DCL(Data Control Language)
   • 데이터 제어 언어, 데이터를 조회할 수 있는 권한을 부여하거나 빼앗을 때 사용
   • GRANT, REVOKE

MYSQL 구조

• 데이터는 표(table)에 저장
• 표들은 데이터 베이스(스키마, shema)
• 이러한 스키마를 모아놓은 것이 데이터 베이스 서버

1. CREATE

스키마 생성

• create database opentutorials;

테이블 생성

• CREATE TABLE topic();

CREATE TABLE topic (
       id INT(11) NOT NULL AUTO_INCREMENT, //자동으로 1씩 증가해서 중복없게
       title VARCHAR(100) NOT NULL,
       description TEXT NULL,
       created DATETIME NOT NULL,
       author VARCHAR(30) NULL,
       profile VARCHAR(100) NULL,
       PRIMARY KEY(id));
//이름 타입(길이) 널여부

생성된 스키마 확인

• show databases;

데이터베이스 선택

• use opentutorials;

테이블 리스트 조회

• SHOW TABLES;
• DESC 테이블명; #테이블의 열 리스트 조회

테이블에 데이터 추가

• INSERT INTO 테이블명 (컬럼명1, 컬럼명2) VALUES (넣을 데이터1, 넣을 데이터2);

insert into topic (title,description,created,author,profile)
values('MySQL','MySQL is...',now(),'egoing','developer');
///id는 AUTO_INCREMENT했으므로 사용x

2. READ

입력한 데이터 가져오기

• SELECT 컬럼명(*) FROM 테이블명;

mysql> select * from topic;
+----+------------+-------------------------+---------------------+--------+---------------------------+
| id | title      | description             | created             | author | profile                   |
+----+------------+-------------------------+---------------------+--------+---------------------------+
|  1 | MySQL      | MySQL is...             | 2023-07-01 22:14:46 | egoing | developer                 |
|  2 | ORACLE     | ORACLE is               | 2023-07-01 22:25:39 | egoing | developer                 |
|  3 | SQL Server | SQL Server is...        | 2023-07-01 22:28:29 | duru   | data administrator        |
|  4 | PostgreSQL | PostgreSQL Server is... | 2023-07-01 22:30:38 | taeho  | data scientist, developer |
|  5 | MongoDB    | MongoDB is...           | 2023-07-01 22:31:32 | egoing | developer                 |
+----+------------+-------------------------+---------------------+--------+---------------------------+
5 rows in set (0.00 sec)

조건 추가

• SELECT 컬럼명 FROM 테이블명 WHERE author=’egoing’;

mysql> select id,title,created,author from topic where author='egoing';
+----+---------+---------------------+--------+
| id | title   | created             | author |
+----+---------+---------------------+--------+
|  1 | MySQL   | 2023-07-01 22:14:46 | egoing |
|  2 | ORACLE  | 2023-07-01 22:25:39 | egoing |
|  5 | MongoDB | 2023-07-01 22:31:32 | egoing |
+----+---------+---------------------+--------+
3 rows in set (0.00 sec)

• select id,title,created,author from topic where author='egoing' order by id DESC; #id를 기준으로 내림차순

mysql> select id,title,created,author from topic where author='egoing' order by id DESC;
+----+---------+---------------------+--------+
| id | title   | created             | author |
+----+---------+---------------------+--------+
|  5 | MongoDB | 2023-07-01 22:31:32 | egoing |
|  2 | ORACLE  | 2023-07-01 22:25:39 | egoing |
|  1 | MySQL   | 2023-07-01 22:14:46 | egoing |
+----+---------+---------------------+--------+
3 rows in set (0.01 sec)

3. UPDATE

• update topic set title='Oracle' where id=2;

4. DELETE

• delete from 테이블 where 조건;

트랜젝션

• 데이터베이스 내에서 하나의 그룹으로 처리해야 하는 명령문들을 모아놓은 작업 단위 ex) 송금
  • 출금과 입금이 1번씩 발생하지만 은행에서는 송금 자체를 하나의 트랜잭션으로 봄
  • 출금, 입금을 하나의 그룹으로 봄

트랜젝션 특징 (ACID)

• 원자성(Atomicity) : 트랜잭션은 DB에 모두 반영되거나, 전혀 반영되지 않아야 함(ALL-OR-Nothing 방식)
  • 올 커밋, 올 롤
  • 정상적으로 종료된 경우, 데이터 베이스 내의 연산 결과 모두 전부 반영
  • 중간에 장애가 발생한 경우, 처음 상태로 모두 되돌려 전부 취소
• 일관성(Consistency) : 트랜잭션이 실행되기 전과 실행된 후의 데이터베이스는 일관성 있는 상태여야 함
  • 일관성 요구조건:A계좌 + B계좌 = 5000
  • 트랜잭션 작업 전후 에도 일관성 요구 조건이 유지되어야 함
• 격리성(Isolation) : 둘 이상의 트랜잭션이 동시 실행되고 있을 때, 각각의 트랜잭션은 서로 간섭 없이 독립적으로 실행되야 함 → 동시성 제어를 통해 구현
  • 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것
  • 트랜잭션 밖에 있는 어떤 연산도 중간 단계의 데이터를 볼 수 없음
• 영속성(Durability) : 트랜잭션이 성공적으로 완료되었으면 결과는 영구적이어야 함
  • 시스템 장애, 손상, 전원 공급 장애 등의 상황이 발생하더라도 데이터는 안전하게 보존되어야 함

→데이터 안정성과 무결성을 보장하기 위해 ACID 트랜잭션 사용

트랜젝션 연산

• Commit : 트랜잭션의 모든 연산이 성공적으로 수행됐을 때, 트랜잭션에서 수행한 모든 변경 내용이 영구적으로 데이터베이스에 반영하게 하는 연산
• Rollback : 트랜잭션 도중 오류가 발생하거나 트랜잭션 내에서 일부 연산이 실패했을 때, 트랜잭션을 실패로 처리하고 이전 상태로 되돌리게 하는 연산

트랜젝션 상태

• 활동 : 트랜잭션이 실행을 시작했거나 실행 중인 상태
• 부분 완료 : 트랜잭션이 모든 연산을 성공적으로 수행하였고, Commit연산을 기다리고 있는 상태
• 완료 : 트랜잭션이 성공적으로 완료되어 Commit연산을 수행한 상태
• 실패 : 트랜잭션 내에서 오류가 발생하여 트랜잭션이 중단된 상태
• 철회 : 트랜잭션 실행에 실패하여 Rollback연산을 수행한 상태

트랜잭션 격리 레벨

• 동시에 DB에 접근할 때 그 접근을 어떻게 제어할지에 대한 설정
• READ-UNCOMMITTED (커밋되지 않은 읽기)
  • 커밋 전의 트랜잭션의 데이터 변경 내용을 다른 트랜잭션이 읽는 것을 허용
  • 더티 리드 (Dirty Read) 발생 : 커밋 이전의 데이터를 보고있을 때, 트랜잭션이 롤백된다면 잘못된 데이터를 보고 있는 것
  • 더티 리드 (Dirty Read) : 특정 트랜잭션에 이해 데이터가 변경되었지만, 아직 커밋되지 않은 상황에서 다른 트랜잭션이 해당 변경 사항을 조회할 수 있는 문제
   
• READ-COMMITTED (커밋된 읽기)
  • 커밋이 완료된 트랜잭션의 변경사항만 다른 트랜잭션에서 조회 가능
  • 커밋되지 않은 데이터에 접근하지 않고, UNDO 영역의 데이터를 접근
  • UNDO 영역 : 데이터의 변경이 있을 경우, 이전의 데이터를 보관하는 곳
  • 더티 리드 해결
  • 반복 불가능한 조회 (Non-Repeatable Read, 논 리피터블 리드) 문제 : 하나의 트랜잭션 내에서는 동일한 셀렉트 쿼리를 날렸을 때 항상 같은 결과를 보장해야 하지만 그러지 못한 것
  • 반복 불가능한 조회 (Non-Repeatable Read) : 같은 트랜잭션 내에서 같은 데이터를 여러번 조회했을 때 읽어온 데이터가 다른 경우
• REPETABLE-READ (반복 가능한 읽기)
  • 트랜잭션 범위 내에서 조회한 내용이 항상 동일함을 보장함
• SERIALIZABLE (직렬화 가능)
  • 한 트랜잭션에서 사용하는 데이터를 트랜잭션이 끝날 때까지 다른 트랜잭션에서 접근 불가
    • 가장 엄격한 격리수준

아래로 내려갈수록 격리 수준은 높아지고 데이터 정합성이 높아져 성능은 낮아짐

데이터 정합성 : 데이터가 일관되고 정확한 상태를 유지하는 것

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

정규화란?

• 테이블 간에 중복된 데이터를 제거하여 무결성을 유지하게 하는 것

정규화 단계

제 1정규화

• 테이블의 컬럼이 원자값(하나의 값)을 갖도록 테이블을 분해하는 것

제 2정규화

• 제 1정규형 릴레이션에서 부분 함수 종속성을 제거하는 것
  • 부분 함수 종속성 : 기본키가 복합키일 경우 기본키를 구성하는 속성 중 일부에게 종속된 것
   

기본키(복합키) : 학생번호, 강좌이름 → 성적

강좌이름(기본키의 부분집합) → 강의실

제 3정규화

• • 이행 함수 종속 : A -> B, B -> C가 성립할 때 A -> C가 성립되는 것
  • 이행 함수 종속의 문제 : 학생번호 → 강좌이름 → 수강료인 경우 강좌 이름이 바뀌어도 학생은 수강료를 그대로 내고 수업을 들을 수 있음, 강좌이름에 맞게 수강료를 변경하는 과정 번거로움제 2정규형 릴레이션에서 이행 함수 종속성을 제거하는 것

BCNF 정규화

• 제 3정규형 릴레이션에서 모든 결정자가 후보키가 되도록 테이블을 분해하는 것

N대M 자기참조 관계 해결방법

• 한 테이블 내의 레코드들 사이에 존재하는 N대 M관계
• 보조 테이블 생성 후 원래 테이블과의 관계를 맺은 후 일대다 관계로 변환

뷰란?

데이터베이스의 하나 이상의 테이블의 필드들로 구성된 가상테이블

뷰의 사용이유?

데이터 무결성을 강화하고 여러 테이블들로부터 동시에 온 데이터로 작업하기 위해 사용

뷰 정의문

CREATE VIEW 뷰이름[(속성이름[,속성이름])]AS SELECT문; //뷰 생성
DROP VIEW 뷰이름 RESTRICT or CASCADE //뷰 삭제

다중 부분 필드 해소

• ex) 이름 - 김예나
• 다중 부분 필드로부터 정보를 추출하고 정렬하는 것은 어려움
• 필드 내의 고유한 항목을 식별 후, 각각의 항목을 개별적인 필드로 나눔
• 강사 이름 필드 → 강사 성 필드, 강사 이름 필드로 나눔
• 강사 주소 필드 → 강사 시, 강사 도, 강사 우편번호 필드로 나눔
• 감추어진 다중 부분 필드가 있을 수도 있으니 주의

다중 값 필드 해소 ex) 사용 언어 - 한국어, 영어, 독일어

• 해선 안 되는 것들
  • 다중 값 필드를 단일 값 필드들로 평탄화하는 것 X
    • 교육 범위들 → 교육범위1, 교육범위2, 교육범위3
  • 하나의 값만 포함하도록 하는 것 X
    • 교육 범위들 카테고리들을 하나의 값만 포함하게 나눔
• 다중 값 필드 해소 절차
  1. 다중 값 필드들이 일대일 연관 같은 것이 있는지 살펴봄
  2. 다중 값 필드들을 기존의 테이블로부터 제거 후, 새로운 테이블로 생성
  3. 새로운 테이블을 기존 테이블과 관계를 맺게 하기 위한 연결 필드 추가 후, 적절한 이름, 종류, 설명 할당
• 다중 값 필드를 해소하기 위한 새로운 테이블들은 중복된 데이터를 포함하지만, 중복이 최소한이므로 허용 가능함. → 설계는 절대적으로 최소한의 중복 데이터만 가질 수 있도록!!

테이블 구조 정제하기

테이블의 필수 요소

• 단일 주제를 나타냄
• 기본키
• 다중 부분, 다중 값 필드 금지
• 계산된 필드 금지
• 불필요한 이중 필드 금지
• 최소한의 중복 데이터 포함

불필요한 이중 필드 해결 : 제 3 정규화

• 두 개의 이중 필드 집합 → 악기1/악기2/악기3 , 대여일1/대여일2/대여일3
• 악기와 대여일은 1대1 관계
• 다중 값 필드 해결방법과 같은 절차로 해결
  1. 다중 값 필드들을 기존의 테이블로부터 제거 후, 새로운 테이블로 생성
  2. 새로운 테이블을 기존 테이블과 관계를 맺게 하기 위한 연결필드 추가 후, 적절한 이름, 종류, 설명 할당

키

키의 종류 - 테이블 내에서의 기능을 결정

후보키

• 테이블에서 설정하는 첫번째 키
• 각 테이블은 적어도 하나의 후보키를 가져야 함
• 후보키들 가운데 하나를 기본키로 지정
• 필수 요소
  • 다중 부분 필드 x
  • 레코드를 유일하게 식별할 수 있는 값이여야 함
  • 널 값x
  • 암호, 사회보장번호 같은 보안과 관련된 값 x
  • 선택적이지 않고 필수적으로 모든 값이 들어가야 함
  • 유일성을 정의하기 위한 필요한 최소 개수의 필드만 포함 → 성,이름 o / 성,이름,직원ID x
  • 고정된 값이여야 함

기본키

• 후보키들 중에서 선택한 하나의 키, 필수요소는 후보키와 동일
• 각각의 테이블은 단 하나의 기본키만 가져야 함

대체키

• 후보키들 중에서 기본키로 사용되지 않은 나머지 키
• 테이블 내의 특정 레코드를 유일하게 식별하는 대체 수단

테이블 무결성 조건

• 이중 레코드 x
• 기본 키가 각 레코드를 유일하게 식별
• 기본키는 유일하고 널이 없어야 함

키 : 독특한 역할을 수행하는 특별한 필드

• 기본키 (Primary Key)
  • 특정 레코드를 유일하게 구별할 수 있는 속성
  • 각각의 테이블은 반드시 기본키를 가져야 함
  • 유일하게 식별되고, 중복되지 않아야 하며, NULL값을 가질 수 없음
   

• 외래키 (Foreign Key)
  • 테이블 사이의 관계를 설정할 때 사용
  • 참조 무결성 : 외래키의 값이 외래키가 참조하는 기본키의 값과 반드시 일치해야 함
  • 첫번째 테이블로부터 기본키의 복사본을 만든 후 두 번째 테이블에 포함시킨 것 → 기본키 ≒ 외래키

인덱스

데이터 베이스에서 검색 속도 향상과 같은 데이터 처리를 향상시키기 위해 만든 물리적인 자료구조

관계 : 테이블 쌍 사이의 연결

• 첫 번째 테이블의 레코드를 두 번째 테이블의 레코드와 연관 시킬 수 있는 것
• 1대1 관계
  • 양 테이블에서 같은 기본키를 공유할 수 있는 유일한 경우
  • 폰 번호는 한 명의 user와 연결, 한 명의 user는 하나의 폰 번호와 연결
   

• 1대 N관계
  • 1명의 user는 여러개의 폰 번호를 가질 수 있고, 여러개의 폰 번호는 1명의 user를 가르킬 수 없음
   

• N대 M관계
  • 1명의 고객은 여러 개의 여행상품을 구매할 수 있고, 1개의 여행 상품은 여러 개의 고객에 의해 구매될 수 있음
  • N대 M관계는 연결 테이블을 이용하여 표현
   

참여의 종류

테이블 대행사, 고객 사이에 관계가 있다고 할 때

• 강제 : 고객 테이블에 새 고객을 삽입하기 전에, 대행사가 반드시 존재해야 하는 경우
• 선택 : 고객 테이블에 새 고객을 삽입하기 전에, 대행사가 필요 없는 경우

데이터 무결성

• 데이터 베이스 내의 데이터의 유효성, 일관성, 정확성 의미
• 테이블 무결성 : 중복된 레코드 X, 필드가 유일하며 NULL이 아닌 것
• 필드 무결성 : 필드가 값이 일관성 있고 정확한 것
• 관계 무결성 : 관계가 정확하고, 관계를 맺은 테이블이 동기화 되는 것(삽입, 삭제, 수정 시)
• 업무 규칙 : 데이터 베이스 내의 제약 또는 규제

데이터 베이스를 적절하게 설계하는 것은 어렵지 않다. 시간이 오래 걸릴 뿐 인내심을 가지고 지름길을 찾지 말아야 한다.

데이터 베이스 설계 단계

1. 임무 명세와 임무 목표 정의
   • 임무 명세 : 데이터 베이스의 목적
   • 임무 목표 : 데이터 베이스의 데이터에 대해 사용자들이 수행하는 일반적인 작업을 나타내는 문장들
2. 현재 데이터 베이스 분석하기(존재한다면)
   • 면담을 통해 관리자가 원하는 데이터 요구 사항 식별
   • 현재 데이터를 수집하고 표현하는 방법 검토
3. 데이터 구조 만들기
   • 테이블과 필드 정의
   • 기본 키 설정
   • 필드 명세(분명하고 자세하게) 설정
4. 테이블 관계 설정
   • 기본 키와 외래 키를 이용하여 관계 설정
5. 업무 규칙 결정 및 정의
   • 데이터 베이스 제약 결정
6. 뷰 설정
   • 데이터로 작업하는 다양한 방법을 식별 후 뷰 설정
7. 데이터 베이스 무결성 검토
   • 테이블 검토
   • 필드 명세 검토
   • 관계의 유효성 검토
   • 업무 규칙 검토

임무 명세와 임무 목표 정의

임무 명세 : 데이터 베이스의 목적을 작성하는 것

• 뉴 스타즈 텔런트 대행사 데이터베이스의 목적은 우리가 생성하는 데이터를 관리하고, 고객들에게 제공하는 약속 서비스와 연예인들에게 제공하는 관리 서비스를 지원하는 정보를 제공하기 위한 것이다.

→ 장황하거나, 목적이 불분명하거나, 여러가지 구체적인 작업을 설명하면 안됨

임무 목표 : 데이터베이스에서 관리되는 데이터에 의해 지원되는 일반적인 작업들을 나타내는 문장들

• 우리는 완전한 환자 주소를 관리할 필요가 있다.
• 우리는 모든 고객 판매를 추적할 필요가 있다.

→ 하나의 작업만 정의, 불필요한 세부사항 포함 X

현재 데이터 베이스 분석하기

• 같은 이름, 특성을 가진 필드(주제) 정제
  • 같은 특성을 가진다면 하나만 남기고 삭제
  • 중복된 특성이지만 다른 주제에 포함 된다면 이름을 바꿈
  • → 테이블의 주제에 맞게 변경
• 테이블인지이 필드인지 구분
  • 특정 주제의 특성 → 필드
  • 어떤 것의 집합을 나타내는 것 → 테이블
  • 더 작은 조각들로 쪼개질 수 있는 것 → 테이블
• 계산된 필드 목록은 제거하고 별도의 목록으로 만듦
  • 문자열 연결, 수학 연산식을 값으로 갖는 것
  • 평균연령, 할인 금액, 고객 수, 금액, 총계, 합계 등..

→ 주제 및 특성 목록(예비 필드, 계산된 필드)를 만듦

테이블 구조 설정하기

데이터 베이스 테이블 : 각각의 주제를 나타냄, 주제를 설명하는 특성을 나타내는 필드로 구성

예비 테이블 목록 정의하기

• 주제 목록 : 사용자와 면담을 수행하는 동안 만든 것
• 예비 필드 목록 : 임무 명세만 보고 객관적으로 만든 것

테이블 정제

• 이중 항목 해소 : 나타내는 주제에 따라 제거 혹은 이름 변경
• 같은 주제를 나타내는 항목 해소
• 주제 목록과 예비 테이블 목록 통합

최종 테이블 목록 정의하기

• 테이블, 필드 이름 설정 규칙
  • 유일하고 애매하지 않고 설명적이게
  • 주제를 명확하게
    • 전화번호x → 집 전화번호, 회사 전화번호
    • 주소x → 고객 주소, 공급자 주소
  • 필요한 최소 개수의 단어 사용 (다용도 탈것 장비 관리x → 장비)
  • 파일, 레코드, 테이블과 같은 단어 사용 금지
  • 테이블 : 약어 사용 금지, 필드 : 의미있고, 이해가능하다면 적절히 사용
  • 데이터를 제한하는 단어 사용 금지 (양주 지역 직원, 포천 지역 직원)
  • 이름에 “그리고, 또는, /, &, 기타” 사용 금지
  • 테이블은 복수형, 필드는 단수형이라고 생각
  • 테이블 설명 작성하기
    • 테이블의 정의
    • 테이블이 왜 중요한지

필드 정제하기

• 필드의 필수 요소
  • 테이블의 특정한 주제를 나타냄
  • 다중 값 필드 안 됨, 하나의 값만 포함 ex) 전화번호 - 1234, 1245, 9437, 3869 안 됨
  • 다중 부분 필드 안 됨 ex) 필드 이름 - 이름과 성
  • 계산되거나 연결된 값 안 됨 → 필드가 다른 필드의 값에 의존하면 안 됨