• 데이터베이스(Database, DB)란? : 데이터의 저장소 (저장 목적), 관리

• DBMS(Database Management System, 데이터베이스 관리 시스템)란? 데이터베이스를 운영하고 관리하는 소프트웨어(관리 목적)
  (계층형, 망형, 관계형 DBMS 중 대부분의 DBMS가 테이블로 구성된 관계형 DBMS(RDMBS)형태로 사용됨)
• 일을 시키는 쪽
• 지금까지 만들어놓았던 데이터베이스를 관리
• 정보를 만들고, 효율적으로 검색하고 접근하고 저장할 수 있게 해줌
• 눈으로 보기에도 편하게 만들어줌
• 우리가 직접 다루기가 어렵기때문에 프로그램을 통해서 쉽게 조작한다고 생각
  ex) MySQL, MariaDB, Oracle과 같은 것들이 바로 DBMS

• SQL(Structured Query Language)란? 구조화된 질의 언어라는 뜻으로 관계형 데이터베이스에서 사용되는 언어. 표준 SQL을 배우면 대부분의 DBMS를 사용할 수 있음.

또한 ACID라는 특성을 가짐

Atomicity(원자성) : 작업들이 하나의 원자단위로서 시행되는 것 (중간에 실패하는 일 없앰)

Consistency(일관성) : 언제나 일관된 DB상태 유지

Isolation(독립성) : 트랜잭션 시에 다른 연산작업이 끼어들지 못하게 함

Durability(지속성) : 영원히 유지됨.

원래 SQL문도 표준 SQL문이 있음
자기들만의 기능들로 우위를 정하려고 함
데이터베이스마다 색을 가지게 됨
지금도 표준 기준으로 움직이긴 하지만 데이터베이스마다 조금씩 다름!

데이터베이스 안에 있는 표에 저장되서 데이터베이스가 됨!
결국 얘를 쓰는건 파일?

파일에 쓰다보니까 똑같은 값이 들어가면 안된다
항상 파일 불러와서 중복되는거 있나없나 우리가 찾았음
우리가 직접 찾거나 지우거나 했었음 오류도 많았음

=> 이걸 데이터 관리하는 파일을 맡김 (Database) / CRUD 작업

이걸 사용하는 논리? 😘

어떻게 읽고 집어넣고 지우고 하는건 맡겨놓고 넌 로직에만 신경을 써라~

CRUD를 문법으로 표현
자바 프로그램에서 SQL문을 어떻게 질의하고 받아오는 기능 => JDBC
자바 데이터베이스 커넥트무ㅏ시기

우리는 CRUD에 집중!!
Read 읽기가 가장 중요~✨

CRUD란?

js / sql 은 계속 공부~

현실 -> 논리 -> 물리
개발 초기 단계에 모델링이 진행될 때 데이터 모델링도 같이 진행
데이터베이스 설계, 모델링 단계는 쉽게 모델링하기 어려움

객체모델링은 우리가 실제로 만들어야 할 대상의 특징을 뽑아냄
상태(멤버변수) / 행위(메서드)로 나누고
실제로 컴퓨터에 존재하는게 물리단계

릴레이션(관계) => table 테이블
사실상 같은 말!

개체 Entity

릴레이션 : 튜플
테이블 : 레코드, row
속성(attribute) : column
번호, 이름, 나이만 싹 다 모은걸 domain

데이터베이스의 성질중에서 계속 증가 , 레코드(행) 수가 늘어남

복수데이터 다룰 때 반드시 필요한것은? 식별자!
인공적으로 번호를 붙일 순 있지만 데이터의 순서가 아님!!

내가 원하는 하나를 반드시 찾아내야 함 DB에서는 이걸 key 라고 함!

레코드 1개가 학생 1명에 매치
내가 원하는 유일한 1명을 찾아내야하는데 그럼 key(식별자)가 필요함!

• 식별성 : 중복되지 않아야함

• 후보키 : 내가 주식별자로 쓸 수 있는 열이 어떤게 있는지 (학번, 주민번호) 이론상으로 존재, 주키의 후보

• 주키(Primary key): PK, 테이블을 구성하고 있는 열 중에서 식별성을 만족하는 열, 외부로 보여져선 안되는 정보는 X (주민등록) , 학번 사용 , 최소성과 식별성이 두개 다 만족되어야 사용가능 / 검색이 다른 열에 비해서 유리 , null값 X

책 같은 경우는
제목 | 저자 | 가격 | 출판사
세개를 묶어서 식별자로 사용하는 경우도 있음 : 이걸 복합키라고 함

• ISBN번호로 하나의 열로만 식별할 수 있음 (최소한의 정보로 식별 / 최소성을 만족)
• 이렇게 쓰면 최소성 만족못함 제목 | 저자 | 출판사
• 식별만을 목적으로 만든 열

주 키로 설정되면 특별한 일이 생김
binary search - 이걸 사용하면 제일 빨리 찾을 수 있음

• 정보가 많으면 많을수록 속도가 느려짐
• 주키로 선언한다는 말은 이걸로 찾을 준비를 데이터베이스에서 하고 있다라는 의미
  찾고 싶으면 이걸로 찾아 내가 도와줄게?ㅎㅎ

• 대체키 : 주 키 대신에 쓸 수 있음, 검색은 같은데 성능이 주키를 따라올 수 없음

• 슈퍼키 : 최소성을 만족(고려)하지 않고 식별성만 만족하는 열의 집합

학번 | 이름
학번 | 이름 | 나이
식별을 할 수 있는 모든 열의 집합

• 외래키(F.K) : 포린키 , 주 키를 다른 테이블에서 참조

학생
학번 | 이름 | 전공 | 담당교수
s001 | A |컴퓨터| P0001

교수
교수ID | 이름 | 나이
P0001 | B | 50

교수 테이블에서 식별자는 교수ID (P.K 프라이머리키)
학생의 담당 교수님을 알기 위해서는 A라는 이름으로 담당교수 ID를 알아야 함
여기서 끝나는게 아니라 P0001을 뽑아내서 교수 테이블에서 참조!
주키를 다른 테이블에서 사용하는 걸 외래키!! => 참조!
자신의 테이블에서 주키, 다른 테이블에서 주키 값을 가져와서 쓰는 것 (연결고리)
주키로 뽑힌 교수 아이디는 중복되는게 없을거임 (주키 / 외래키)

이건 질의문할때 서브커리로 나옴

유니크(unique) : 똑같은 값이 여러개 존재하지 않음 / null 허용 / key는 null이 안됨 / key는 수정불가

하나 이상의 열로 구성된 주키 (Complex Key복합키)

무결성 : 말그대로 결점이 없는 데이터, 무결성을 지키지 않는 값을 쓸 수 없음
내가 데이터로 쓰려면 무조건 저건 지켜야 함!
크게 보면 3개로 나눌 수 있음

도메인 : 열들의 집합

• 개체 무결성 : 개체가 아무리 많아도 내가 원하는 개체를 찾아내야 함 , 모든 테이블에는 주키(P.K)가 있어야 함 (식별자가 있어야 함)
• 도메인 무결성 : 나이 제한(type 크기, 범위) 제약하는 범위 들어 갈 수 있는 값의 종류, 범위가 들어감 , 조건에 맞는거만 들어감, 도메인(종류, 범위 ...)

학생
학번 | 이름 | 담당교수
s001 | 윤중두 | P001
s002 | 춘식이 | P002

교수
교수ID | 이름 | 성별
P001 | A | 남자
P002 | B | 여자

=> 참고 무결성 만족

학생
학번 | 이름 | 담당교수
s001 | 윤중두 | P001
s002 | 춘식이 | P002

교수
교수ID | 이름 | 성별
P001 | A | 남자
P003 | B | 여자

• 참조 무결성
  => 이런 경우, 대상이 없는걸(존재하지않는 값) 참조할 때 무결성이 깨졌다고 (NullPointException과 같음)

정규화 (Normalization)

1차 정규화 부터 5차 정규화
대용량 테이블에서 사용
🎈면접을 위해서 1차부터 3차까지만 알고 있으면 됨!

1차 정규화 (1NF)

• 열(도메인)은 원자적 값만 포함
• 같은 데이터가 여러 열에 반복되지 말아야 함

P.K는 ____ 끄어서 표현 : 복합키

• 항목 하나에 값이 복수 개가 들어가는 걸 원자적이지 않다고 함
  ex) 동아리 : 태권도, 요리

  원자성 : 동등한 2개의 값이 한개의 항목으로 들어가있음 / 테이블이 쪼개짐

2차 정규화(2NF)

• 1차 정규화에 만족해야 함
• ✨완전 함수 종속 구현 (P.K) 부분 함수 종속 제거(일부 종속 X)
• P.K가 복합키일때 발생
• 전체키에 대해서 종속되어있지않고 일부분에 종속되어있는걸 소거하는 작업
• 하나의 속성으로 P.K가 구성된 경우 이미 2NF 에 만족

완전 함수 종속이란?
공급자번호, 부품번호 -> 수량

부분 함수 종속이란?
공급자번호가 소재지를 결정
하나가 바뀌면 따라 바뀐다

삽입 이상

삽입 레코드

• 공급자 : S5, 소재지 : 부산
• 기본키가(공급자 번호, 부품번호) 이므로, 부품을 제공하지않는 공급자는 삽입이 불가능

갱신 이상

한개에 같이 있으면 안되는 정보 그래서 계속 같은 정보가 생김
차수가 많으니 일부분의 정보를 저장하는게 불가능해짐

3차 정규화 (3NF)

• 이행적(추이적) 함수 종속 제거
  Xa -> ;X.b
  Xb -> ;X.c

모든 테이블의 열은 주키에만 종속되어야 함
주키가 아닌 열에 종속되어있으면 안됨

정규화의 목적?

중복제거 / 똑같은 데이터가 여러개 나오면서 일관성이 무너짐
각 정규화 단계를 거치지않으면 이상현상이 발생
이상현상을 막기위해

운송 거리는 소재지에 종속되어짐
공급자번호 <- 소재지 <- 운송거리

• 삽입 이상 : 강릉, 237km
  특정 도시의 운송거리 저장 불가
  공급자 정보가 없을 경우 (P.K)

• 삭제 이상
  S4에 대한 레코드를 삭제한다면?
  광주 운송거리 또한 삭제됨

• 갱신 이상
  운송거리 변경으로인한 일관성을 잃을 잠재적 가능성 존재
  (같은 지역에 다수의 공급자가 존재 할 경우)

ERD