코딩스토리

관계형 모델 제약조건 관계형 모델 제약조건에는 크게 3가지가 있다. 1. Inherent model-based constraints - Implicit(내재적, 묵시적) 제약조건이라고도 하며 Relation 모델이기 때문에 지켜져야 하는 제약 조건들같이 암묵적으로 모델 자체에서 내포하고 있는 제약조건이다. ex) Tuple들은 순서가 없고 중복이 되면 안 됨 (Relational은 tuple들의 집합이기 때문에) 2. Schema-based constraints - Explicit(명시적) 제약조건이라고도 하며 스키마에서 직접적으로 표현되는 제약조건들이다. ex) Key constraints(키 제약조건), Referential Integrity constraints(참조 무결성 제약조건) 등 3. Ap..

JDBC 프로그래밍을 할 때 아래와 같은 오류를 만나본 사람이 꽤 많을 것이다. java.sql.SQLException: Access denied for user 'root'@'localhost' (using password: YES) 여기서야 검은색 글씨로 써져 있으니 괜찮아 보이지만 프로젝트 실행하고 저 오류를 빨간색으로 본다면.. 열불이 난다. 이미 많은 사람들이 해결법을 제시하고 있다. "using password: YES" 란 말이 비밀번호를 잘못 입력한 경우기 때문에 비밀번호를 재설정하고 다시 권한을 주라 등등... 근데 나는 프로젝트를 처음 실행할 때는 저런 오류가 없다가 어느 순간 생겼다. 비밀번호를 바꾸지도 않았는데! 희망고문도 아니고 되다가 안 되는 건 뭐냐고!!! 뭐 이 정도 에러는 ..

ERD(Entity Relationship Diagram) DB를 설계하다 보면 이들의 관계가 어떤지, FK, PK가 뭔지 등 테이블 간의 관계를 알고 싶을 때가 있다. 이럴 때 사용되는 것이 ERD이다. ERD란 개체 관계 모델, 즉 Entity, 테이블 관계를 설명해주는 다이어그램이다. 아래의 예시를 보자. 총 5개의 테이블이 있다. Product, OderLine, Order, OrderStatus, Customer 5개의 테이블이 각각의 관계를 가지고 있다. 만약 이러한 DB를 설계했다면 DB 설계자는 자기가 설계했기 때문에 기억할 수 있겠지만 며칠 뒤에 보면 까먹을 수도 있고, 다른 사람에게 DB를 설명해야 할 수도 있다. 이때 위처럼 ERD를 보여주면 한눈에 이해하기 쉬울 것이다. 아래는 ER..

현재 2021 OSS 컨트리뷰톤을 진행 중인데 이미 PR을 보낸 commit의 indentation에 문제가 있음을 확인했다. 가독성도 굉장히 떨어지고 기분도 찝찝하기에 저 indentation 오류를 해결해야겠다고 마음먹었지만... Git린이에게 큰 시련이 닥쳤다.. 바로 해당 PR에 commit이 쌓여버렸다는 점! indentation 오류를 고쳐야 하는 commit이 가장 옛날 commit이었다 ㅠㅠ 이러한 경우 commit을 고치는 방법이 있다! 지금부터 이 과정을 기록해놓으려고한다. (맨날 까먹거든요) 간단하게 과정먼저 설명해보면 다음과 같다. 과거의 commit으로 돌아간다. commit을 수정한다. 다시 원래 시점으로 돌아온다. 말은 간단하지만 처음 해보면 쉽지는 않다.. 지금부터 차근차근 ..

ON UPDATE CASCADE는 참조하고 있는 다른 테이블의 컬럼(FK)들도 같이 UPDATE 하겠다는 제약 조건이다. ON UPDATE CASCADE는 아래와 같은 예시에서 사용된다. 먼저 아래와 같이 두 개의 테이블이 있다고 가정해보자. COURSE SECTION COURSE 테이블은 과목명과 과목 번호를 가지고 있고, SECTION 테이블은 어떠한 과목이 어떤 학기에 열리는지를 담고 있다. 이때 두 테이블의 PK, FK, 관계를 살펴보면 COURSE 테이블의 PK는 Course_number이고 SECTION 테이블의 Course_number는 COURSE 테이블의 Course_number의 FK이다. 즉 SECTION 테이블의 Course_number는 COURSE 테이블의 Course_numbe..