728x90
반응형
SMALL

* Youtube Review - https://www.youtube.com/watch?v=64c0BgeCLAY&list=PL6i7rGeEmTvpLoDkB-kECcuD1zDt_gaPn&index=2

 

개발 방법론 중 기본은 폭포수 모델이다.

기획(요구사항) -> 설계 -> 개발 -> 테스트 -> 운영

운영시에도 계획/분석/설계는 매우 중요하다.

추상적의 반댓말은 구체적

전사적 (EA) 은 Enterprise Architecture 기업입장에서 본다는 의미이다.

예를 들어 전기에 대한 프로젝트가 있다면 개발자는 개발의 지식만 갖고 있고 현업에서 업무 프로세스를 주는 방식이다.

DBMS는 oracle, mysql, sql server 등 굉장히 다양한 데이터베이스가 있다. 개념적 데이터 모델링은 모든 DBMS에서 사용할 수 있다.

결과물인 ERD를 생성하는 것이다.

요구사항을 그린다.

사람들이 화면의 왼쪽 상단부터 본다고 한다.

그래서 보통 중요한 엔터티를 왼쪽 상단에 둔다.

연관이 있을 것 같은 엔터티끼리 연결해준다.

관계명은 기술되어 있지 않는 경우도 많다.

엔터티 안의 인스턴스들이 얼마나 참여하는지

필수여부는 0또는 1를 표시함으로써 표시한다.

이를 ERD라고 한다.

상세하게 그려야 한다. 그래서 업무, 속성, 관계 등 정의

재사용성이 높음, 이 모델링 한 결과물은 설계할 때만 사용하는 것이 아니다. 구축 또는 테스트시 계속 사용한다.

또한 유지보수 해야한다.

논리적 데이터 모델링은 특정 DBMS에 종속적이다.

논리적 데이터 모델링을 할 때 정규화를 수행한다.

먼저 속성을 쭉 나열하는 것이다.

식별자에 대한 요구조건이 있다.

주민등록번호보다 직원ID가 더 부합하기 때문에 직원ID를 PK로 사용한다.

만약 직원이 두개 이상의 연락처를 갖을 수 있으면, 직원 연락처로 나누어 주어야 한다.

파급효과: 초반에 엉망으로 설계하면 개발하다가 나중에 엎게 되어 힘듬

2. 간결한 설계또가 있어야 쉽게 이해 가능

3. 데이터 중복, 비유연성, 비일관성 등 이상한 데이터가 안 들어감

데이터의 중복이 일어나면 다음과 같이 한 ID에 여러 데이터가 조회되는

데이터 중복 현상이 발생한다.

사소한 프로세스(업무)의 변화에도 테이블을 바꿔야 하는 경우

연락처가 변경되면 이를 이력에 쌓아야 한다.

스키마는 각각 종속적이다.

개념 스키마와 내부 스키마의 독립성

저장공간 (하드 디스크) 등을 데이터베이스에 추가해도 개념 스키마를 변경할 필요 없다.

유일하게 인스턴스를 식별할 수 있다.

(1) 대표성 여부: 직원 ID 는 주식별자, 주민등록번호는 보조식별자

(2) 스스로 생성 여부: 내부식별자는 테이블 내부의 PK이다. 외부식별자는 외부 테이블에서 빌려온 FK이다.

(3) 단일속성여부: 단일식별자는 하나의 식별자이다. 복합식별자는 직원연락처처럼 2개이상의 식별자 조합이다. 예를 들어 직원연락처는 직원ID와 구분코드로 식별자가 조합되어 있다.

(4) 대체여부: 본질식별자는 업무 본연에 있던 대상이다. 인조식별자

예를 들어 부서명을 식별자로 사용하여도 된다. 근데 너무 길다. 인프라, 서비스, 통신. 하나 코드 따서 만들자.

D001, D002 등이다. 편의를 위해서 임의로 만든 식별자를 인조식별자라 한다.

실무 입장에서는 주민번호는 암호화가 되어야 한다.

주식별자 도출기준 특징

1. 유일성

2. 최소성

3. 불변성

4. 존재성

 

감사합니다.

728x90
반응형
LIST

+ Recent posts