IT / 금융 3 // 21.07.28.

💰 0. 실습

1) 논리 - 개념 모델 변환

2) 정규화1

3) 정규화2

4) 특수상황을 대비한 모델링

막상 실습해보니 굉장히 난해하다.
어떤 것부터 고려해야 할 지 순서를 정하고, 절차에 맞춰서 한 단계씩 진행해야 할 것 같다.
한번에 idea가 떠올라서 구조를 짜면 오히려 error 가능성..

💰 1. 변수형

• CHAR와 VARCHAR의 차이는 가변임.
  CHAR은 고정 : "안녕" 이어도 사실 "안녕 "
  VARCHAR은 가변 : "안녕" 이면 "안녕"

• VARCHAR와 NVARCHAR의 차이는 byte 수 / 글자 수
  VARCHAR은 byte : VARCHAR(6) "안녕하"
  NVARCHAR은 글자 수 : NVARCHAR(6) "안녕하세요안"

💰 2. 정규화

• 제 1정규화 : 반복 / 복수 속성 제거
  ex) 품목이 추가될 때마다 품목번호1/품목명1/구매수량1 column을 추가시 굉장한 낭비

• 제 2정규화 : 기본 key에 종속되지 않는 속성 제거
  ex) 구매번호(PK)/품목번호(PK)/품목명/구매수량일 때
  품목번호(PK)/품목명 Entity - 구매번호(PK)/품목번호(PK)/구매수량 Entity 분리

• 제 3정규화 : 기본 key가 아닌 속성에 종속되는 속성 제거
  ex) 구매번호/구매요청일자/구매담당/공급자번호/공급자명 Entity (PK = 구매번호)를
  구매번호(PK)/구매요청일자/구매담당/공급자번호 Entity와 공급자번호(PK)/공급자명 Entity 분리

💰 3. 개발자 Mind

• 순차적 사고 방식 / 설계는 대충해도 프로그램으로 / 로직이 최고 / 데이터는 100만건 이상은 많아

가 아니고

• 단일 책임 원칙 / 추상적집합적 사고 방식 / 좋은 모델링 / 1,000만건은 거뜬

💰 4. 메타 데이터

• 데이터들의 데이터 / 통일시켜 일관된 관리 / 표준용어 표준단어의 조합 / 반드시 숙지하고 작업 들어가자.

💰 5. 코드

• 관계의 집합이 한정되어있으면 모델러의 코드

• 단순 나열은 코드가 아님.

💰 6. 기타 학습사항

• PK를 잘 잡고 시작하자.
• 논리모델 / 물리모델 똑같을 순 없다. 엄밀한 의미에서.

💰 7. SOLID

• SRP (Single Responsibility Principle) : 단일 책임 원칙

1. 작성된 클래스는 하나의 기능만 가지며 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어야 함.
2. Guitar Class의 serialNumber, price 요소 중 sN은 불변, price는 가변이므로 price를 GuitarSpec Class로 뺌.

• OCP (Open Close Principle) : 개방 폐쇄 원칙

1. 소프트웨어의 구성요소(Component, Class, Module, Function)는 확장에 열려있고, 변경에 닫혀있어야 함.
2. 변경 비용을 줄이고 확장 비용을 극대화
3. 요구사항의 변경이나 추가가 발생하더라도, 기존 구성요소는 수정이 일어나지 말아야 함.
4. Guital Class만 사용한다면 상관 없으나, Bass Class가 추가된다면?? 일일히 만들어야 하는가??
5. 추가될 악기들의 공통 속성을 담을 StringInstrument Interface를 생성한다.

• LSP (Liskov Substitution Principle) : 리스코브 치환 원칙

1. 서브 타입은 언제나 기반 타입으로 교체할 수 있어야 함.
2. LinkedList를 사용하는 메소드는, Collection을 사용하는 메소드로 바꾼다. 속도 개선을 위해 HashSet을 사용하는 issue가 발생해도 영향 없음.

• ISP (Interface Segregation Principle) : 인터페이스 분리 원칙

1. 자신이 사용하지 않는 인터페이스는 구현하지 않아야 함.
2. column을 추가하고 listener를 부착하는 등 여러 역할이 하나의 클래스 안에 혼재되어 있지만 인터페이스 분리를 통해 특정 역할군을 이용할 수 있도록 함.

• DIP (Dependency Inversion Principle) : 의존성 역전 원칙

1. 구조적 디자인에서 발생하던 하위 레벨 모듈의 변경이 상위 레벨 모듈의 변경을 요구하는 위계관계를 끊는 역전.