< 인덱스(Index) 개념 >

• 인덱스는 데이터를 빠르게 찾을 수 있는 수단으로서, 테이블에 대한 조회 속도를 높여 주는 자료 구조이다.
• 인덱스는 테이블의 특정 레코드 위치를 알려 주는 용도로 사용한다.
• 인덱스는 자동으로 생성되지 않는다.

• 기본 키(PK; Primary Key) Column은 자동으로 인덱스가 생성된다.
• 연월일이나 이름을 기준으로 하는 인덱스는 자동으로 생성되지 않는다.
• '테이블의 이름' Column에 index가 없는 경우, 테이블의 전체 내용을 검색한다.(테이블 전체 스캔; Table Full Scan).
• 인덱스가 생성되어 있을 때 데이터를 빠르게 찾을 수 있다.(인덱스 범위 스캔; Index Range Scan).
• 조건절에 '='로 비교되는 컬럼을  대상으로 인덱스를 생성하면 검색 속도를 높일 수 있다.

< 인덱스(Index)의 종류 >

< 인덱스(Index) 생성 및 삭제, 변경 하기 >

[생성]

CREATE [UNIQUE] INDEX 인덱스명 ON 테이블명(컬럼명);

여기서 [ ]는 생략 가능해도 되고 안해도 된다는 것.

UNIQUE : 인덱스 걸린 컬럼에 중복 값을 허용하지 않는다.

인덱스명 : 생성하고자 하는 인덱스 테이블명

테이블명 : 인덱스 대상 테이블명

컬럼명 : 테이블의 특징 컬럼명(복수 컬럼 지정 가능)

예를 들어  CREATE UNIQUE INDEX A ON STUDENT(ID); 이렇게 인덱스를 만들 수 있다.

혹은 UNIQUE를 생략하고 

CREATE INDEX idx_employee_name
ON Employee (name);

이렇게도 만들 수 있다. 

[삭제]

DROP INDEX 인덱스명;

여기서 '인덱스명'은 생성된 인덱스명을 의미하며, 인덱스를 테이블의 종속 구조로 간주하고, 삭제 시 테이블 변경 명령어가 사용된다. ALTER TABLE 명령 뒤에 DROP INDEX 명령이 추가되는 형태로 사용 된다.

[변경]

ALTER [UNIQUE] INDEX 인덱스명 ON 테이블명(컬럼명);

일부 제품은 인덱스에 대한 변경 SQL 문이 없다.

기존 인덱스를 삭제 하고 신규 인덱스를 생성하는 방식으로 사용이 권고 된다. 

이를 실제로 생성부터 데이터 삽입과 인덱스 생성, 인덱스를 사용해서 데이터를 검색하는 쿼리를 구현하면 다음과 같다.

[employee Table 생성]

CREATE TABLE employee (
  id INT PRIMARY KEY AUTO_INCREMENT,
  first_name VARCHAR(50) NOT NULL,
  last_name VARCHAR(50) NOT NULL,
  birth_date DATE,
  hire_date DATE
);

[데이터 삽입]

INSERT INTO employee (first_name, last_name, birth_date, hire)
VALUES ('윤태영', '박', '1920-03-14', '1935-10-01');

[인덱스 생성]

CREATE INDEX idx_employee_last_name
ON employee (last_name);

[인덱스 사용]

SELECT * 
FROM employee
WHERE last_name = '박';

※주의점: 데이터 삽입, 변경이 수시로 일어나면 매번 인덱스를 변경해야 하므로, 성능 저하를 막기 위한 고려가 필요하다. 

Reference : 2023 수제비 정보처리기사

https://product.kyobobook.co.kr/detail/S000200275590

< View의 개념 >

• View는 논리 테이블로서 사용자에게(생성 관점 아닌 사용 관점에서) 테이블과 동일하다.
• View는 TABLE A와 같은 하나의 물리 테이블로부터 생성 가능하며, 다수의 테이블 또는 다른 뷰를 이용해 만들 수 있다.
• View와 같은 결과를 만들기 위해 Join 기능을 활용할 수 있으나, View가 만들어져 있다면 사용자는 조인 없이 하나의 테이블을 대상으로 하는 단순한 질의어를 사용할 수 있다.

< View 장단점 >

[장점]

논리적 독립성 제공 : 데이터베이스에 영향을 주지 않고 애플리케이션이 원하는 형태로 데이터에 접근 가능하다.

데이터 조작 연산 간소화 : 애플리케이션이 원하는 형태의 논리적 구조를 형성하여 데이터 조작 연산을 간소화 한다.

복수 테이블에 존재하는 여러 종류의 데이터에 대해 단순한 질의어 사용이 가능하다.

보안 기능(접근제어) 제공 : 특정 필드만을 선택해 View를 생성할 경우 애플리케이션은 선택되지 않은 필드의 조회 및 접근이 불가 하다. 

또한 중요 보안 데이터를 저장 중인 테이블이나 컬럼에는 접근이 불허된다.

[단점]

View 자체 인덱스 불가 : 인덱스는 물리적으로 저장된 데이터를 대상으로 하기에 논리적 구성인 뷰 자체는 인덱스를 가지지 못한다.

View 변경 불가 : 뷰의 정의를 변경하려면 뷰를 삭제하고 재생성 해야한다. 뷰 정의는 ALTER 문을 이용하여 변경할 수 없다.

(View는 CREATE 문을 사용하여 정의, 뷰를 제거할 때는 DROP문을 사용한다.)

데이터 변경 제약 존재 : 뷰의 내용에 대한 삽입,삭제,변경 제약이 있다. 

< View 명령어 >

① 뷰 생성

• 뷰 생성의 일반 형태는 다음과 같다.

SELECT문에는 UNION이나 ORDER BY절을 사용할 수 없다.컬럼명을 기술하지 않으면 SELECT 문의 컬럼명이 자동으로 사용된다.

②뷰 삭제/변경

• 뷰 정의 자체를 변경하는 것은 불가능하다.
• 뷰 이름이나 쿼리문을 변경하는 수단은 제공되지 않는다.
• 뷰 삭제와 재생성을 통해 뷰에 대한 정의 변경이 가능하다.

ⓐ DROP VIEW 문법

DROP VIEW 문법은 다음과 같다.

DROP VIEW 테이블명 [CASCADE | RESTRICT];

ⓑ DROP VIEW 명령어 옵션

DROP VIEW 명령어의 옵션에는 CASCADE와 RESTRICT가 있다.

CASCADE : 참조하는 테이블까지 연쇄적으로 제거하는 옵션

RESTRICT : 다른 테이블이 삭제할 테이블을 참조 중이면 제거하지 않는 옵션 

Source :2023 수제비 정보처리기사

https://product.kyobobook.co.kr/detail/S000200275590

🤔 < Join?>

DataBase는 현대 Business의 핵심 요소 중 하나이다. 기업은 수십, 수백, 심지어는 수억 개의 Recode를 관리해야 할 수도 있다. 이런 Data를 효과적으로 관리하려면 구조화된 방식이 필요하고, 그래서 RDBMS를 사용하고 있다.

RDBMS에서 가장 기본 개념 중 하나가 바로 "Join"이다.

📟 < Join! >

Join은 여러 Data Table을 관련성이 있는 Column을 기준으로 연결하는 방법이다. 이를 통해 단일 쿼리로 여러 Table의 Data를 수집할 수 있게 된다. 대표적으로 INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL JOIN 등이 있다.

이제 INNER JOIN부터 해서, FULL JOIN까지 자세히 알아보자.

🔥 < Inner Join > 

Inner Join : "두 개 이상"의 Table에서 공통으로 존재하는 Recode만을 반환한다.

Inner Join은 Join 방식 중 가장 엄격한 일치 조건을 필요로 한다. 즉, Join 하는 Table 간에 일치 값이 없다면 결과는 아무것도 표시되지 않는다.

🌈 < Inner Join 장점 >

정확성 : Table 간에 완벽 일치하는 Recode를 반환하기에, 정확성을 보장한다.

효율성 : 불필요한 Recode를 제거함으로써 Database 효율성을 높인다.

간결성 : Inner Join을 통해 여러 Table 관련 정보를 한 줄의 Query로 가져온다. 

 < 예제 SQL >

'Employees' 'Departments' Table이 있다.

 < Employees Table>

< Departments Table >

다음 SQL Query는 Inner Join을 사용하여 'Employees' Table과 Departments Table을 Join 하고, 각 직원의 이름과 해당 직원이 속한 부서의 이름을 반환한다.

SELECT Employees.EmployeeName, Departments.DepartmentName
FROM Employees
INNER JOIN Departments ON Employees.DepartmentID = Departments.DepartmentID;

 이 쿼리의 결과 Table은 다음과 같다.

여기에서 "김지민"은 결과에 제외되어있다. 이유는 그의 DepartmentID인 400은 Departments Table에 존재하지 않기 때문이다. 이처럼 INNER JOIN은 양쪽 테이블에서 일치하는 레코드만 반환한다.

다른 예제를 또 보자면, 이번에는 Employees Table에서 DepartmnetID가 200 이상인 직원과 그들의 부서를 찾는 쿼리다.

SELECT Employees.EmployeeName,Departments.DepartmentName
FROM Employees
INNER JOIN Departments ON Employees.DepartmentID = Departments.DepartmentID
WHERE Employees.DepartmentID >= 200;

이 Query의 결과 Table은 다음과 같다.

김지민은 DepartmentID가 400이어서 200이상인 조건에 만족하지만, Departments Table에 DepartmentID가 400이 없기에 Inner Join의 결과에서 제외된다.

🔥 < Left Join > 

Left Join은 SQL의 주요 명령어 중 하나로, Left Table의 모든 Recode와 Right Table에서 일치된 Recode를 반환해준다.Right Table에서 일치하는 Recode가 없으면 null값.

🐱‍👤 < Left Join 장점 >

완정성 : Left Table의 모든 Data를 보존하면서 동시에 Right Table의 일치 데이터를 가져올 수 있다. 이는 데이터 완전성을 보장한다.유연성 : 일치하는 Data가 없더라도 Left Table의 Data를 모두 표시한다. 이로 인해 데이터 분석 시 유연성을 제공한다.

< 예제 SQL >

(앞서 언급한 Employees Table과 Departments Table을 다시 사용한다)

아래의 SQL Query는 Left Join을 사용하여서 Employees Table과 Departments Table을 Join 해서 각 직원의 이름과 해당 직원이 속한 부서의 이름을 반환한다.

SELECT Employees.EmployeeName, Departments.DepartmentName
FROM Employees
LEFT JOIN Departments ON Employees.DepartmentID = Departments.DepartmentID;

이 Query의 결과는 다음과 같다.

여기서 김지민의 부서 이름이 NULL로 표시된다. 왜냐하면 김지민의 DepartmentID인 400이 Departments Table에 존재하지 않기 때문이다.

다른 예제를 보자. 이번에는 Employees Table에서 DepartmentID가 200 이상인 직원과 그들의 부서를 찾는 Query다.

SELECT Employees.EmployeeName, Departments.DepartmentName
FROM Employees
LEFT JOIN Departments ON Employees.DepartmentID = Departments.DepartmentID
WHERE Employees.DepartmentID >= 200;

 이 Query의 결과는 다음과 같다.

이와 같이, Left Join은 Left Table의 모든 Recode를 보존하면서도 Right Table의 일치하는 Recode를 가져오므로

데이터의 완정성을 유지하면서 동시에 필요한 정보를 추출할 수 있다.

🔥 < Right Join> 

Right Join은 SQL의 주요 명령어 중 하나로, Right Table의 모든 Recode와 Left Table에서 일치된 Recode를 반환한다.

Left Table에 일치 Recode가 없으면 Null값.

🐱‍🏍 < Right Join 장점 >

Right Table 중심 : Right Table의 모든 Data를 보존과 동시에 Left Table Data를 가져온다.

이는 Right Table에 중점을 두면서 Data를 조사하려는 경우 유용하다.

유연성 : 일치하는 Data가 없더라도 Right Table의 Data를 모두 표시한다. 이로 인해 데이터 분석 시 유연하다.

< 예제 SQL >

( Employees와 Departments Table을 다시 사용한다 )

아래의 SQL Query는 Right Join을 사용하여서 Employees Table과 Departments Table을 Join 하여서, 각 직원 이름과 해당 직원이 속한 부서의 이름을 반환한다.

SELECT Employees.EmployeeName, Departments.DepartmentName
FROM Employees
RIGHT JOIN Departments ON Employees.DepartmentID = Departments.DepartmentID;

이 Query의 결과는 아래와 같다.

여기서 Marketing 부서는 직원이 없기 때문에 EmployeeName은 NULL 표시된다.

이번에는 Departments Table에서 DepartmentID가 200 이상인 부서와 그 부서에 속한 직원들을 찾는 Query다.

SELECT Employees.EmployeeName, Departments.DepartmentName
FROM Employees
RIGHT JOIN Departments ON Employees.DepartmentID = Departments.DepartmentID
WHERE Departments.DepartmentID >= 200;

이 Query 결과 Table은 아래와 같다.

이처럼, Right Join은 Right Table의 모든 Recode를 보존함과 동시에 Left Table의 일치 Recode를 가져오므로, 완정성 유지와 필요 정보를 추출할 수 있다.

Reference Documents :
https://dev.mysql.com/doc/refman/8.0/en/join.html
https://www.w3schools.com/sql/sql_join.asp

🤔정규화(Normalization) 란?

Normalization : "중복을 제거하며, 일관성을 개선하는 Process"

< 정규화 하는 이유 >

⒧.데이터의 수정(삽입, 삭제, 갱신) 이상현상을 제거하기 위해

⑵.데이터 중복을 최소화 하기 위함

🌳정규화의 단계 

< 제1정규형 (1NF) >

모든 행이 같은 수의 열을 가져야 하고, 각 열의 값이 더 이상 분할할 수 없는 원자적 값이어야 한다. 예를 들어, 학생이 수강하는 과목을 하나의 열로 표현한다고 한다면.

이 열에 'Math, Science'와 같이 여러 과목을 쉼표로 구분하여 넣는다면, 이는 1NF를 위반하는 것이다. 왜냐하면 '수학, 과학'은 더 이상 분할할 수 있는 값이기 때문이다. 1NF를 만족시키려면, 각 과목을 별도의 행으로 분리해야 한다.

CREATE TABLE Students (
StudentID INT,
NAME VARCHAR(100),
Subjects VARCHAR(100)
);

Insert INTO Students VALUES (1, 'Jone Doe', 'Math, Science');
Insert INTO Students VALUES (2, 'Jane Doe', 'Math, English');

위의 Students Table은 1NF를 위반하는 Table이다.  Subjects에 'Math, English'  이렇게 여러 과목을 Insert하여 원자성을 위반 하기 때문이다.

1NF를 위반하고 있는 Student Table을 만족하는 코드는 아래와 같다.  

CREATE TABLE Students (
 StudentID INT,
 Name VARCHAR(100)
 );
 
 CREATE TABLE StudentSubjects (
 StudentID INT,
 Subject VARCHAR(100)
 );
 
 INSERT INTO Students VALUES (1, 'John Doe');
 INSERT INTO StudentSubjects VALUES (1, 'Math');
 INSERT INTO StudentSubjects VALUES (1, 'Science');
 
 INSERT INTO Students VALUES (2, 'Jane Doe');
 INSERT INTO StudentSubjects VALUES (2, 'Math');
 INSERT INTO StudentSubjects VALUES (2, 'English');

이 경우, 'Students' Table은 학생 정보만을, 'StudentSubjects'테이블은 학생이 수강하는 과목 정보를 각각 저장하고 있다.이는 각 컬럼의 값이 원자적이라는 1NF의 원칙을 만족하는 것이다.

이를 테이블로 표현하면 다음과 같다.

< Students Table >

 < StudentSubjects Table >

< 제2정규형 (2NF) >

2NF는 1NF를 만족하는 테이블에 대해 추가적인 규칙을 제공한다. 2NF를 만족하려면, 테이블의 모든 기본 키가 아닌 열이 기본 키에 완전히 종속되어야 한다. 이는 "부분적 종속성"이 없어야 한다는 것을 의미한다.

부분적 종속성이란, 복합 키(두 개 이상의 열로 구성된 키)의 일부에만 종속되는 열이 존재하는 상황을 말한다.

예를 들어, 학생이 수강하는 과목에 대한 정보를 기록하는 테이블이 있다고 가정해 보자. 이 테이블의 기본 키는 '학번'과 '과목명'으로 구성되어 있다. 이때 '교수명'이라는 열이 '과목명'에만 종속되어 있다면, 이는 2NF를 위반하는 것이다. 왜냐하면 '교수명'은 기본 키의 일부인 '과목명'에만 종속되기 때문이다. 이 경우, 과목에 대한 정보가 여러 곳에 중복되어 저장될 수 있다.

CREATE TABLE StudentCourses (
StudentID INT,
CourseName VARCHAR(100),
ProfessorName VARCHAR(100)
);

INSERT INTO StudentCourses VALUES (1, 'Math', 'Professor A');
INSERT INTO StudentCourses VALUES (1, 'Science', 'Professor B');
INSERT INTO StudentCourses VALUES (2, 'Math', 'Professor A');

위의 코드에서 'ProfessorName'열은 'CourseName'에만 종속되어 있다. 이는 2NF를 위반하는 것이다.

2NF를 만족하는 코드는 아래와 같다.

CREATE TABLE Students (
    StudentID INT,
    Name VARCHAR(100)
);

CREATE TABLE Courses (
    CourseName VARCHAR(100),
    ProfessorName VARCHAR(100)
);

CREATE TABLE StudentCourses (
    StudentID INT,
    CourseName VARCHAR(100)
);

INSERT INTO Students VALUES (1, 'John Doe');
INSERT INTO Courses VALUES ('Math', 'Professor A');
INSERT INTO Courses VALUES ('Science', 'Professor B');
INSERT INTO StudentCourses VALUES (1, 'Math');
INSERT INTO StudentCourses VALUES (1, 'Science');
INSERT INTO StudentCourses VALUES (2, 'Math');

위의 코드에서 'Students' 테이블은 학생 정보만을, 'Courses' 테이블은 강좌와 강좌를 담당하는 교수의 정보를, 'StudentCourses' 테이블은 학생이 수강하는 강좌의 정보를 각각 저장하고 있다. 이는 각 열이 기본 키에 완전히 종속되어 있으므로 2NF를 만족한다.

이를 테이블로 표현하면 다음과 같다. 

      < Students Table >

                                                                         < Courses Table >

< StudentCourses Table >

< 제3정규형 (3NF) >

3NF는 Table이 2NF를 만족하면서 추가로 '이행적 종속성'이 없어야 함을 요구한다. 이행적 종속성이란, A가 B에 종속되고 B가 C에 종속될 때, A가 C에 간접적으로 종속되는 관계를 말한다. 3NF는 이러한 이행적 종속성을 허용하지 않는다.

예를 들어, 학번(StudentID), 과목명(CourseName), 교수명(ProfessorName)이라는 열이 있는 테이블에서 '과목명'이 '교수명'에 종속되고, '학번'이 '과목명'에 종속되는 경우, '학번'은 '교수명'에 이행적 종속성을 가진다고 할 수 있다. 이는 3NF를 위반하는 것이다. 이행적 종속성을 제거하려면, '교수명'을 별도의 테이블로 분리하고, 이 테이블의 기본 키를 '과목명'으로 설정해야 한다.

CREATE TABLE StudentCourses (
    StudentID INT,
    CourseName VARCHAR(100),
    ProfessorName VARCHAR(100)
);

INSERT INTO StudentCourses VALUES (1, 'Math', 'Professor A');
INSERT INTO StudentCourses VALUES (1, 'Science', 'Professor B');
INSERT INTO StudentCourses VALUES (2, 'Math', 'Professor A');

위의 코드는 3NF를 위반하는 코드 예시이다.  위의 코드에서 'ProfessorName' 열은 'CourseName'에 종속되어 있으며, 'StudentID' 열은 'CourseName'에 종속되어 있다. 따라서 'StudentID'는 'ProfessorName'에 이행적 종속성을 가지며, 이는 3NF를 위반하는 것이다.

3NF를 만족하는 코드는 아래와 같다.

CREATE TABLE Students (
    StudentID INT,
    Name VARCHAR(100)
);

CREATE TABLE Courses (
    CourseName VARCHAR(100),
    ProfessorName VARCHAR(100)
);

CREATE TABLE StudentCourses (
    StudentID INT,
    CourseName VARCHAR(100)
);

INSERT INTO Students VALUES (1, 'John Doe');
INSERT INTO Courses VALUES ('Math', 'Professor A');
INSERT INTO Courses VALUES ('Science', 'Professor B');
INSERT INTO StudentCourses VALUES (1, 'Math');
INSERT INTO StudentCourses VALUES (1, 'Science');
INSERT INTO StudentCourses VALUES (2, 'Math');

위의 코드에서 'Students' 테이블은 학생 정보만을, 'Courses' 테이블은 강좌와 강좌를 담당하는 교수의 정보를, 'StudentCourses' 테이블은 학생이 수강하는 강좌의 정보를 각각 저장하고 있다. 이는 각 열이 기본 키에 완전히 종속되어 있으며 이행적 종속성이 없음을 의미하므로, 3NF를 만족한다. 이와 같이 3NF를 만족하는 설계는 데이터의 중복을 최소화하고 무결성을 보장한다.

이를 테이블로 표현하면 다음과 같다. 

< Students Table >

< Courses Table >

< StudentCourses Table > 

Reference : 
정규화(Normalization) 쉽게 이해하기 - 아무튼 워라밸 (hleecaster.com)

DBMS의 정규화: 1NF, 2NF, 3NF 및 BCNF [예] (hackr.io)

🤔 동시성 제어란 ?

동시성 제어는 여러 트랜잭션을 동시에 실행하면서도 데이터베이스의 일관성과 격리성을 보장하기 위한 기법이다.

여러 사용자가 동시에 같은 데이터에 엑세스할 때 충돌을 방지하는데 필요하다.

💯동시성 제어의 두 가지 기법

< 잠금(Locking)> < 타임스탬프(Timestamp)>

잠금(Locking) 기법: 잠금 기법에서는 데이터 항목에 대해 '잠금(lock)'을 설정하여 다른 트랜잭션들이 해당 데이터에 액세스하는 것을 제한한다. 잠금은 일반적으로 '읽기 잠금(공유 잠금)'과 '쓰기 잠금(배타적 잠금)'의 두 가지 유형이 있다. 읽기 잠금은 해당 데이터 항목을 읽을 수는 있지만 수정할 수는 없게 하며, 쓰기 잠금은 해당 데이터 항목을 읽거나 쓸 수 있는 트랜잭션을 한 개로 제한한다.

타임스탬프(Timestamp) 기법: 타임스탬프 기법에서는 각 트랜잭션에 고유한 타임스탬프를 할당하여 트랜잭션의 순서를 정한다. 이 기법은 트랜잭션들이 동일한 데이터에 대해 순차적으로 액세스하도록 강제함으로써 충돌을 방지한다.

이러한 기법들을 통해 DBMS는 동시에 실행되는 여러 트랜잭션들 사이에서 데이터의 일관성을 유지하고 무결성을 보장한다.

🥺 < 동시성 제어를 하지 않을 시 발생하는 문제 > 

갱신 손실 (Lost Update): 두 트랜잭션이 동시에 같은 데이터를 변경하려고 할 때, 한 트랜잭션의 변경이 다른 트랜잭션에 의해 덮어쓰여질 수 있다.

비완료 의존성 (Dirty Read): 한 트랜잭션이 아직 커밋되지 않은 변경을 읽는 경우, 그 트랜잭션이 롤백되면 일관성 없는 데이터를 보게 될 수 있다.

계층형 읽기 (Non-repeatable Read): 한 트랜잭션 도중에 같은 데이터를 두 번 이상 읽는 경우, 그 사이에 다른 트랜잭션이 그 데이터를 변경하고 커밋할 경우, 같은 트랜잭션 내에서 데이터의 일관성이 깨질 수 있다.

팬텀 읽기 (Phantom Read): 한 트랜잭션 도중에 일련의 행 (예를 들어, 특정 조건을 충족하는 행)을 두 번 이상 읽는 경우, 그 사이에 다른 트랜잭션이 새 행을 삽입하고 커밋할 경우, 같은 트랜잭션 내에서 일련의 행이 변경되는 현상을 볼 수 있다.

Reference :

GeeksforGeeks - Concurrency Control in DBMS

TutorialsPoint - DBMS Concurrency Control

DataBase에서 Key는 Data를 구분,관리하는 데 매우 중요한 역할을 한다.

주로 기본키(PK),외래 키(FK),고유 키(UK),체크 키(CK),후보키 등의 종류가 있다.

< 기본 키(Primary Key, PK) >

기본 키는 Table에서 각 행을 고유하게 식별하는 열이다. 기본 키의 특징은 다음과 같다.

• 고유성 : 각 행에 대해 유일한 값을 가져야 한다.
• 무결성 : NULL값을 허용하지 않는다.
• 테이블당 하나의 PK만 설정 가능하다.

Employees Table에서 PK를 사용했다고 가정하면 다음과 같다.

CREATE TABLE Employees (
ID INT PRIMARY KEY,
LastName VARCHAR(255) NOT NULL,
FirstName VARCHAR(255),
Address VARCHAR(255),
City VARCHAR(255)
);

<외래 키(Foreign Key, FK) >

외래 키는 다른 테이블의 기본 키나 고유 키를 참조할 수 있다.

고유 키는 각 행이 고유한 값을 가져야 하지만 NULL 값을 허용할 수 있다. 이는 고유 키가 기본 키와 다른 주요한 특징 중 하나이다.
따라서 외래 키가 참조하는 고유 키의 값이 NULL인 경우도 있을 수 있다. 하지만 이는 일반적으로 권장되지 않습니다. 외래 키는 데이터 무결성을 보장하는 데 중요한 역할을 하는데, 참조하는 키의 값이 NULL인 경우 데이터 무결성을 유지하는 데 문제가 발생할 수 있기 때문이다.

따라서 가능한 한 외래 키는 NULL이 아닌 고유한 값을 가진 기본 키나 고유 키를 참조하도록 설계하는 것이 좋다.

외래키의 특징은 아래와 같다.

• 참조 무결성: 외래 키의 값은 참조되는 기본 키의 값 중 하나이거나 NULL이어야 한다.
• RDBMS에서 Table 간의 관계를 나타낸다.
• 하나의 테이블에 여러 외래 키를 설정할 수 있다.

외래 키 예시를 들면, Orders 테이블에서 Employees 테이블을 참조할 수 있다.

CREATE TABLE Orders (
    OrderID INT PRIMARY KEY,
    OrderNumber INT NOT NULL,
    EmployeeID INT,
    FOREIGN KEY (EmployeeID) REFERENCES Employees(ID)
);

< 고유 키(Unique Key, UK) >

고유 키는 테이블의 각 행을 고유하게 식별할 수 있는 열이다. 기본 키와 비슷하지만, NULL 값을 허용한다는 점이 다르다.

고유 키의 특징은 아래와 같다.

• 각 행에 대해 유일한 값을 가져야 한다.
• NULL값을 허용할 수 있다.
• 하나의 테이블에 여러 고유 키를 설정할 수 있다.

고유 키는 다음과 같이 설정할 수 있다. 

CREATE TABLE Employees (
    ID INT PRIMARY KEY,
    LastName VARCHAR(255) NOT NULL,
    FirstName VARCHAR(255),
    Email VARCHAR(255) UNIQUE
);

Email 열은 고유 키로 설정되어 각 행의 Email 값은 고유해야 한다.

< 체크 키(Check Key, CK) >

체크 키는 특정 열의 값이 지정된 조건을 만족해야 함을 보장하는 제약 조건이다.

체크 키의 특징은 아래와 같다.

• 데이터의 유효성 보장 한다.
• 열에 대해 지정된 조건을 만족해야 한다.
• 하나의 테이블에 여러 체크 키를 설정할 수 있다.

체크 키는 다음과 같이 설정할 수 있다.

CREATE TABLE Employees (
    ID INT PRIMARY KEY,
    LastName VARCHAR(255) NOT NULL,
    FirstName VARCHAR(255),
    Age INT CHECK (Age >= 18)
);

Age 열은 체크 키로 설정되어 Age 값이 18 이상이어야 한다.

< 캔디데이트 키(Candidate Key) >

캔디데이트 키는 기본 키로 선택될 수 있는 키다.

캔디데이트 키는 고유성(uniqueness)과 최소성(minimality)을 만족해야 한다.

고유성: 캔디데이트 키가 테이블의 각 행을 고유하게 식별할 수 있어야 한다는 것. 이것은 테이블에 동일한 값의 캔디데이트 키를 가진 두 개 이상의 행이 있으면 안된다는 의미다. 예를 들어, 학생 테이블에서 학생 ID는 고유성을 가지는 키일 수 있다. 왜냐하면 각 학생은 고유한 ID를 가지므로, 이 ID를 통해 각 학생을 "정확하게 식별"할 수 있기 때문이다.
최소성: 캔디데이트 키는 가능한 작은 수의 열로 구성되어야 한다는 것이다. 이것은 캔디데이트 키의 모든 부분이 행을 식별하는 데 필요하다는 의미이다. 예를 들어, 만약 학생 테이블에서 학생 ID와 성별을 결합하여 캔디데이트 키를 만들었다면, 이 키는 최소성을 만족시키지 못한다. 왜냐하면 학생 ID만으로도 각 학생을 고유하게 식별할 수 있기 때문이다. 따라서, 성별 열은 캔디데이트 키에서 불필요하게 된다.

예를 들어, 학생들에 대한 정보를 저장하는 'Students' 테이블이 있다고 가정해 보자.

CREATE TABLE Students (
StudentID INT,
Email VARCHAR(255),
FirstName VARCHAR(255),
LastName VARCHAR(255)
);

여기서 'StudentID'와 'Email' 열은 각각 Candidate Key가 될 수 있다. 왜냐하면 이들은 각각 학생들을 고유하게 "식별"할 수 있기 때문이다. 따라서 이들 중 하나를 기본 키로 선택할 수 있다.

CREATE TABLE Students (
StudentID INT PRIMARY KEY,
Email VARCHAR(255) UNIQUE,
FirstName VARCHAR(255),
LastName VARCHAR(255)
);

이 예제에서 'StudentID'는 기본 키로 선택되었고, 'Email'은 고유 키로 설정되었다.

이 두 키 모두 Candidate Key이다.

PK로 선택되지 않은 Candidate Key("Email")은 대체 키(alternate key)라고도 부른다.

이는 기본 키로 선택될 수 있는 대체 선택지라는 의미다.

그럼 어떤 상황에서 alternate key가 pk로 대체 될까?

1) 비즈니스 요구사항 변경 : 비즈니스 요구사항이 변경되어 기존 PK가 더이상 각 행을 유일하게 식별하지 못하거나,

새로운 요구사항을 충족시키지 못하는 경우 대체 키를 기본 키로 변경할 수 있다.

2. 데이터 구조 변경: 테이블의 데이터 구조가 변경되어 기존 PK가 더 이상 적절하지 않은 경우 대체 키를 기본 키로 변경할 수 있다. 예를 들어, 테이블을 분할하거나 병합하는 경우 기존의 기본 키가 더이상 유용하지 않을 수 있다. 

이러한 상황 외에 테이터베이스의 설계방식에 따라 다양한 방식에서 대체 키가 기본 키로 사용될 수 있다. 

데이터베이스 관리 시스템(DBMS):다양한 종류의 데이터베이스를 효율적으로 관리하기 위한 소프트웨어이다.

< 주요 기능 >

데이터 정의: DBMS는 '데이터 정의 언어(DDL)를 사용해 데이터베이스 구조를 정의하고 수정할 수 있다. 예를 들면, 테이블 생성이나 인덱스 설정 같은 것이 있다.

데이터 분석 및 관리: '데이터 조작 언어(DML)'를 사용해 데이터베이스에서 원하는 데이터를 찾거나 수정할 수 있다. 대표적인 예로는 SQL(Structured Query Language)이 있다.

데이터 보안 및 접근 권한: '데이터 제어 언어(DCL)'를 통해 데이터베이스 접근 권한을 설정하고 보안을 관리한다. 권한 부여 및 회수, 제약 조건 설정 등을 통해 데이터를 안전하게 보호할 수 있다.

관리와 최적화: DBMS는 데이터베이스의 성능을 향상시키고 효율적인 관리를 위한 다양한 기능을 제공한다. 데이터 저장, 인덱싱, 캐싱 등을 자동적으로 처리해 준다.

복구와 백업: 무시할 수 없는 중요한 기능 중 하나는 데이터 복구와 백업이다. DBMS는 데이터 손실을 방지하고 안전하게 저장할 수 있도록 데이터베이스를 주기적으로 백업한다. (예를 들어 오라클에는 Hot Backup，Cold Backup， RMan Backup，Export Backup이 있다.)


애플리케이션과 시스템들은 이런 DBMS 도구를 이용해 데이터를 구조화하고 저장하며, 관리하고 검색하는 역할을 하고 있다. 대표적인 DBMS 제품으론 Oracle Database, MySQL, Microsoft SQL Server, PostgreSQL, MongoDB 등이 있다.

참고: https://www.ibm.com/docs/en/cics-ts/5.4?topic=processing-acid-properties-transactions 

https://www.techopedia.com/definition/27386/consistency-databases

DataBase의 "일관성(Consistency)"은 Transaction이 성공적으로 완료되어도 항상 데이터베이스를 일관된 상태로 유지해야 한다는 원칙을 의미 한다.

즉, Transaction의 실행 결과가 데이터베이스의 일관성을 유지하는 데 기여하는 무결성 제약 조건을 준수해야한다는 것을 의미한다.

< 일관성을 보장하는 Transaction의 예시 > 

START TRANSACTION;

-- 송금자 계좌에서 돈을 빼기
UPDATE Accounts SET balance = balance - 1000 WHERE account_id = 1;

-- 수신자 계좌에 돈 추가
UPDATE Accounts SET balance = balance + 1000 WHERE account_id = 2;

COMMIT;

위의 코드에서는 "START TRACSACTION"과 "COMMIT" 사이에 이루어지는 모든 작업이 원자성을 가지기에

이에 따라 일관성이 보장 된다. 

< 트랜잭션 실행결과가 무결성 제약 조건을 준수해야 하는 이유 >

1) 정확성 보장 :

무결성 제약조건은 데이터가 정확하고 유효한 값만 가지도록 보장한다.

예를 들어, 특정 필드에는 숫자만 입력되어야 하며, 또 다른 필드에는 NULL 값이 허용 되지 않는 등의

규칙을 설정할 수 있다.

2) 일관성 유지 :

무결성 제약조건은 데이터베이스의 일관성을 유지하는데 중요한 역할을 한다.

예를 들어, 외래 키 제약 조건은 RDBMS에서 Table간의 관계를 정의하고 유지하는데 사용한다.

이를 통해 무효한 데이터나 참조 무결성 오류를 방지할 수 있다.

3) 신뢰성 ↑ :

무결성 제약조건이 준수되면, 데이터베이스에 저장된 정보가 신뢰성이 높아진다.

이는 비즈니스 결정이나 분석에 사용되는 데이터의 품질이 보장되므로, 더 나은 결과를 얻을 수 있다. 

따라서, 트랜잭션의 실행결과가 무결성 제약조건을 준수하도록 하는 것은 데이터베이스 시스템의 정확성,일관성,신뢰성을 보장하는데 필수적이다. 

< 무결성 제약 조건 >

1.Domain constraints condition in RDBMS : 각 열은 명시적으로 선언된 도메인(예:숫자, 문자열, 날짜 등)의 값만 가져야 한다.도메인이란 데이터베이스 테이블의 특정 열에 허용되는 값의 집합을 말한다.

예를 들어, 개발자가 특정 필드의 타입을 '정수(int)'로 설정했다면, 그 필드에는 정수 값만 입력될 수 있다.

만약 문자열(String)이나 다른 데이터 타입 값이 그 필드에 입력되려고 하면, 데이터베이스 시스템은 그것을 거부하고 오류 메세지를 반환할 것이다.

2.기본 키 제약 조건: 기본 키는 테이블의 각 레코드를 고유하게 식별하는 역할을 한다.

그래서 기본 키 필드는 고유한 값만 가져야 하며, NULL 값을 가질 수 없다. 즉, 같은 테이블에 어떤 레코드도 같은 기본 키 값을 가질 수 없다. (두 개의 테이블이 있다고 가정 했을 때, 두 개의 테이블에 같은 이름을 가진 기본키가 있어도 된다.

기본 키 제약 조건은 같은 테이블 내에서 각 레코드를 고유하게 식별할 수 있어야 한다는 것을 의미한다. 즉, 동일한 테이블 내에서 같은 기본 키 값을 갖는 레코드가 있으면 안된다는 것.)

3.외래 키 제약 조건: 외래 키는 다른 테이블의 특정 레코드를 참조하는 역할을 한다. 외래 키 필드의 값은 참조하는 테이블의 기본 키 값 중 하나여야 한다. 이를 통해 관계형 데이터베이스에서 테이블 간의 관계를 정의하고 유지할 수 있다.

4.사용자 정의 제약 조건: 개발자 또는 데이터베이스 관리자가 특정 비즈니스 규칙이나 도메인 규칙을 데이터베이스에 추가하기 위해 설정하는 조건.

예를 들어 '나이'라는 열의 값이 0보다 크고 120보다 작아야 한다는 규칙을 사용자 정의 제약 조건으로 설정할 수 있다.

이는 나이 값이 현실적인 범위 내에 있어야 한다는 제약을 나타낸다.

< 사용자 정의 제약 조건 예제 코드 (MySQL) >

--테이블 생성
CREATE TABLE Users (
id INT PRIMARY KEY,
name VARCHAR(50),
age INT,
CONSTRAINT CHK_AGE CHECK (age > 0 AND age < 120)
);

< Mysql 설치 방법>

①."mysql community installer windows" Google에 검색한다.

②. Windows(x86, 32-bit), MSI Installer을 Download 한다. (이후 나오는 창에서
"No thanks, just start my download"로 Login 없이 다운로드 가능 하다.)

③. Developer Default를 하고, Next를 누른다. ④ 사진에 나오는 Password 입력하는 것이 나올 때까지 계속 Next 누른다.

④. root 계정의 비밀번호를 설정하고 기억해 둔다.

⑤. 설치가 완료되었으면, "시작창에 MySQL Workbench 8.0 CE"를 검색하여 MySQL에 접속한다.

⑥. 빨간 네모 박스를 클릭하여, "Connect to MySQL Server"창을 띄운 후, ④에서 설정했던 Password를 입력 후, OK를 클릭한다. 

⑦. 아래와 같이 접속이 되면, MySQL 접속 완성

< DBeaver 설치 방법>

①."dbeaver" Google에 검색한다.

②. Download를 한다.

③. Windows(installer)를 클릭해서 Download 한다.

④. 설치된 DBeaver를 시작창에서 검색하여 접속한다.

⑤. 데이터베이스 -> 새 데이터베이스 연결을 클릭한다.

⑥. MySQL을 클릭 후 다음을 누른다.

⑦. Password 부분의 빨간색 네모 박스에 Mysql 설치 시, 설정 한 Password를 입력 후 완료 하고, 설치하라고 하는 것은 설치한다.

⑧. 설치 후 아래와 화면이 나오면 성공 (성공하지 못한 경우, Mysql 접속이 안되어 있는 경우가 있으니, 확인해보아야 한다.)

트랜잭션은  더 이상 쪼갤 수 없는 업무 처리의 최소 단위이다.

 A라는 사람이 B라는 사람있는데 1,000원을 지급하고 B가 그 돈을 받은 경우, 이 거래 기록은 더 이상 작게 쪼갤 수가 없는 하나의 트랜잭션을 구성한다. 만약 A는 돈을 지불했으나 B는 돈을 받지 못했다면 그 거래는 성립되지 않는다. 이처럼 A가 돈을 지불하는 행위와 B가 돈을 받는 행위는 별개로 분리될 수 없으며 하나의 거래내역으로 처리되어야 하는 단일 거래이다. 이런 거래의 최소 단위를 트랜잭션이라고 한다. 트랜잭션 처리가 정상적으로 완료된 경우 커밋(commit)을 하고, 오류가 발생할 경우 원래 상태대로 롤백(rollback)을 한다.

트랜잭션은 데이터베이스에서 데이터의 일관성과 무결성을 보장하기 위해 사용된다.

트랜잭션은 일반적으로 다음과 같은 4가지 속성을 가진다.

원자성(Atomicity): 트랜잭션의 모든 작업이 완전히 수행되거나, 아니면 전혀 수행되지 않아야 한다. 즉, 트랜잭션 내의 작업 중 어느 하나라도 실패하면 전체 작업이 롤백되어야 한다.

일관성(Consistency): 트랜잭션 수행 전과 수행 후의 데이터베이스 상태가 일관되어야 한다. 즉, 트랜잭션 수행 후에도 데이터베이스의 제약 조건이 유지되어야 한다.

격리성(Isolation): 여러 개의 트랜잭션이 동시에 수행되더라도, 각각의 트랜잭션은 독립적으로 수행되는 것처럼 보여야 한다. 즉, 다른 트랜잭션에서 수행하는 작업에 대해 영향을 받지 않아야 한다.

지속성(Durability): 트랜잭션이 성공적으로 완료된 후에는, 해당 작업의 결과가 영구적으로 데이터베이스에 반영되어야 한다. 즉, 시스템 장애 또는 기타 문제가 발생해도 데이터의 일관성과 무결성이 유지되어야 한다.

다음은 JPA를 사용하여 트랜잭션을 시작하고, 데이터 변경 작업을 수행한 후에 트랜잭션을 커밋하거나 롤백하는 예시 코드다.

EntityManager entityManager = entityManagerFactory.createEntityManager();
EntityTransaction transaction = entityManager.getTransaction();

try {
    transaction.begin(); // 트랜잭션 시작
    // 데이터 변경 작업 수행
    Product product = entityManager.find(Product.class, 1L);
    product.setName("새로운 상품명");

    transaction.commit(); // 트랜잭션 커밋
} catch (Exception ex) {
    transaction.rollback(); // 트랜잭션 롤백
} finally {
    entityManager.close();
}

위 코드에서는 EntityManager를 사용하여 엔티티를 조회하고, 엔티티의 속성을 변경하는 데이터 변경 작업을 수행한다. 이러한 데이터 변경 작업은 트랜잭션 내에서 수행되어야 한다. 따라서, 트랜잭션을 시작하고, 변경 작업을 수행한 후에는 반드시 트랜잭션을 커밋하거나 롤백해야 한다.

트랜잭션을 커밋하면, 영속성 컨텍스트에서 변경 사항이 데이터베이스에 반영된다. 반면에 트랜잭션을 롤백하면, 변경 사항은 모두 취소되어 원래의 상태로 복원된다. 이를 통해 데이터 일관성을 유지할 수 있다.

< 주로 활용 되는 곳 >

은행 및 금융 업무: 은행 및 금융 기관에서는 트랜잭션을 사용하여 계좌 이체, 입출금, 거래 기록 등의 금융 업무를 처리한다. 트랜잭션을 통해 동시성 문제를 해결하고 데이터의 일관성과 정확성을 유지할 수 있다.

온라인 쇼핑 및 결제: 온라인 쇼핑몰이나 결제 시스템에서 트랜잭션은 주문 처리, 결제 처리, 재고 관리 등의 업무에 활용된다. 고객이 주문을 생성하거나 결제를 수행할 때, 트랜잭션은 데이터의 일관성과 결제 과정의 안전성을 보장한다.

예약 시스템: 항공사, 호텔, 렌터카 등의 예약 시스템에서는 동시성을 관리하고 데이터의 일관성을 유지하기 위해 트랜잭션을 사용한다. 여러 사용자가 동시에 예약을 시도하더라도 충돌이나 중복 예약을 방지하여 데이터의 정확성과 일관성을 유지할 수 있다.

자원 관리 시스템: 자원 관리 시스템에서는 트랜잭션을 사용하여 자원의 예약, 할당, 해제 등의 작업을 처리한다. 예를 들어, 컴퓨터 자원의 할당이나 데이터베이스의 락(lock) 관리 등에서 트랜잭션이 활용한다.

비즈니스 프로세스 관리: 비즈니스 프로세스 관리 시스템(BPM)에서는 트랜잭션을 사용하여 여러 단계의 작업을 원자적인 단위로 처리하고, 중간 상태에서의 실패를 방지하여 데이터 일관성과 정확성을 유지한다.

이 외에도 트랜잭션은 데이터베이스 시스템의 안정성과 신뢰성을 보장하는데 핵심적인 역할을 한다. 다양한 업무 및 응용 분야에서 트랜잭션이 활용되어 데이터의 일관성과 정확성을 유지하고 동시성 문제를 해결할 수 있다.