APP 개발 단계에서의 데이터 모델링 관계 다이어그램을 ERD로 구성. 개체,관계,속성 식별. 특정 제품, 기술에 준하지 않는 구현. 개념적인 디자인 설계. ERD를 테이블에 매핑. 정규화 구현. 기본 3단계이상 정규화. 정규화 검증. 정규화된 ERD를 DB제품에 적용. 컬럼 인덱싱, 테이블 파티셔닝, 디스크 할당등… 예상 성능 튜닝.

<완성된 데이터모델링의 특징> 데이터 모델링의 특징 및 과정 ◎ 해당 업무의 현재 모씁뿐만 아니라 계획, 정책, 전략을 포함 ◎ 명명법, 도메인등 정의된 규칙에 따른 일관성 있는 모델 ◎ 실무 업무 전문가가 참여하여 실무 내용이 충분히 포함된 내용 ◎ 물리 설계로의 전환이 효율적으로 이루어질 수 있는 모델 ◎ 엔티티, 속성, 관계등에 대한 기본 업무 배경의 객관적 증거 존재 ◎ 업무 변형이나 확장이 발생할 때 수용 가능한 모델 <완성된 데이터모델링의 특징> <데이터모델링 진행 과정>

개념 디자인(Entity) 1) 개체(Entity) 정의 2) 개체(Entity) 명명 3) 개체(Entity) 식별 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 것으로 영속적으로 존재하는 단위. 테이블 매핑시 테이블 명에 해당 할 수 있는 단위. 2) 개체(Entity) 명명 1. 현업에서 사용하는 용어 사용. 2. 약어 사용 자제. 3. 단수 명사 사용. 4. 모든 엔티티 타입명은 유일. 5. 엔티티 생성 의미대로 이름 부여. 3) 개체(Entity) 식별 1. 업무 기술서, 장표, 인터뷰 정리 문서등에서 명사 구분. 2. 불분명한 개념, 광범위한 개념 제거. 3. 엔티티타입의 특성이나 속성값은 제거. 4. 포괄적인 업무 프로세스에 해당되는 명사는 제거. 5. 중복되는 명사는 제거. 6. 누락된 엔티티타입의 존재 유추.

개념 디자인(Entity) 4) 개체(Entity) 식별 예 시나리오) 인터넷 경매를 하는 IAuctionCo라는 회사는 경매할 물품에 대한 내용을 온라인으로 접수받고 각 물품이 팔리 수 있는 날짜(공고일)를 정하여 인터넷에 경매 공고한다. 경매 공고일에는 역시 온라인을 통해 입찰인이 입찰된 물품을 매수 신청하고 매수 신청한 입찰인 중 최고가를 신청한 매수 신청인에게 물품이 낙찰된다. 물품 낙찰일로부터 1주일 이내에 낙찰대금을 은행계좌나 카드 또는 직접 IAuctionCo에 납부하지 않으면 낙찰은 자동으로 취소되고 차순위 금액을 신청한 매수 신청인에게 물품이 낙찰된다. 낙찰인은 1주일 이내에 대금을 납부하면 경매가 성사되었다고 하고 매수 신청인에게 낙찰대금을 입금하여 경매 절차가 완료된다. 경매가 성사되는 경우 물품가격의 2%를 IAuctionCo에 수수료로 납부해야 한다. 각 경매일에 경매가 진행된 결과는 자세하게 알 수 있어야 한다. 1.시나리오에서 명사 구분 인터넷경매, IAuctionCo, 회사, 경매, 물품, 내용, 온라인, 입찰, 접수, 날짜, 경매 공고일, 인터넷, 경매 공고, 입찰인, 매수 신청, 최고가, 신청, 매수 신청인, 낙찰, 낙찰일, 1주일, 낙찰대금, 은행계좌, 카드, 직접납부, 자동, 취소, 차순위 금액, 낙찰인, 대금 납부, 경매 성사, 입금, 물품가격, 2%, 수수료, 경매일, 진행, 결과. 2.광범위하거나 불분명한 개념 제거 3. 엔티티타입의 특성이거나 속성의 값 제거. 물품, 온라인, 입찰, 접수, 날짜, 경매 공고일, 인터넷, 경매 공고, 입찰인, 매수 신청, 최고가, 신청, 매수 신청인, 낙찰, 낙찰일, 1주일, 낙찰대금, 은행계좌, 카드, 직접납부, 자동, 취소, 차순위 금액, 낙찰인, 대금 납부, 경매 성사, 입금, 물품가격, 2%, 수수료, 경매일, 진행, 결과.

개념 디자인(Entity) 5) 개체(Entity)를 ERD로 표현 4. 포괄적인 업무 프로세스에 해당되는 명사 제거. 물품, 온라인, 입찰, 접수, 인터넷, 경매 공고, 입찰인, 매수 신청, 신청, 매수 신청인, 낙찰, 자동, 취소, 낙찰인, 대금 납부, 경매 성사, 입금, 진행, 결과. 5. 중복되는 명사 제거. 물품, 입찰, 접수, 인터넷, 경매 공고, 입찰인, 매수 신청, 신청, 매수 신청인, 낙찰, 낙찰인, 진행. 6. 누락된 엔티티타입 정보 유추. 물품, 입찰, 접수, 인터넷, 경매 공고, 낙찰, 낙찰인, 진행, 경매물품. 5) 개체(Entity)를 ERD로 표현 접수 경매물품 물품 경매공고 진행 매수신청 입찰 낙찰인 낙찰

개념 디자인(Relatioinship) 1) 관계(Relationship) 정의 두 개의 엔티티 사이의 노리적인 관계 즉 엔티티와 엔티티가 존재의 형태나 행위로서 서로에게 영향을 주는 형태를 말한다. 2) 관계(Relationship) 카디낼러티 두 개츼 엔티티타입 간 관계에서 참여자의 수를 표현하는 것을 Cardinality라고 한다. 표현법은 1:1, 1:M, M:N 이다. 3) 관계(Relationship) 식별 1. 업무 기술서, 장표, 인터뷰 정리 문서 등에서 동사를 구분하다. 2. 도출된 엔티티타입과 관계를 이요하여 관계 정의서를 작성한다. 3. 고객에게 질문하여 관계를 더 세분화하고 정확하게 도출하는 작업을 한다. 4. 데이터모델링 툴이나 칠판, 포스트 잇을 이용하여 모델을 직접 그려본다. 5. 고객과 협의하여 모델을 검토, 검증한다.

개념 디자인(Relatioinship) 4) 관계(Relationship) 식별 예 셈플) 여러 부서에 소속된 각각의 사원은 고객으로부터 필요한 제품을 주문 받아 처리하는 일을 한다. 각각의 관계를 질문한 겨로가 다음 관계정의 표와 같은 결론을 얻게 되었다. 기준 Entity 관계 형태(방향, 참여도, 참여방법) 참여 관련 Entity 고객 각각의 고객은 여러 번 주문할 수 있다. 각 주문은 반드시 한 고객에 의해 주문된다. 선택 필수 주문 제품 각각의 제품은 여러 개의 주문을 접수 받을 수 있다. 사원 사원 한명은 여러 개의 주문을 접수 받을 수 있다. 각각의 주문은 한 사원에 의해서만 접수받는다. 부서 각각의 부서에는 여러 명의 사원을 포함한다. 각각의 사원은 하나의 부서에만 포함된다.

개념 디자인(Relatioinship) 4) 관계(Relationship) 식별 예의 ERD 적용 부서 고객 부서코드 고객번호 사원 접수 제품 사원번호 제품번호 고객번호(FK) 접수번호 부서코드(FK) 사원번호(FK)

개념 디자인(Attribute) 1) 속성(Attribute) 정의 2) 속성(Attribute) 명명 업무에 필요한 엔팉티에서 관리하자 하는 더 이상 분리되지 않는 최소의 데이터 단위. 2) 속성(Attribute) 명명 해당 업무에서 사용하는 이름을 부여한다. 서술식 속성명은 사용하지 않는다. 약어 사용은 가급적 자제한다. 엔티티타입에서 유일하게 식별 가능 하도록 지정한다.

개념 디자인(Attribute) 3) 속성(Attribute) 식별의 예 시나리오) 이 쇼핑몰은 일반적인 형태의 온라인쇼핑몰의 특성을 지니고 있다. 회원 가입을 받고, 가입 받은 회원들을 대상으로 과자 제품을 판매한다. 판매된 제품들에 대해서 쇼핑몰 운영자가 주문 처리를 담당한다. 회원 가입시 회원의 고유한 아이디와 이름, 암호, 전화 번호, 주소와 같은 정보들을 입력받고 이 회원이 쇼핑몰의 메일링 리스트를 이용할 것인지에 대한 정보도 등록받는다. 이 쇼핑몰에서 판매되는 제품은 과자류로 '쿠키' 혹은 사탕'과 같은 대분류를 가지고, 제품의 생산자와 제품 가격, 이미지, 간단한 설명 등의 정보들을 가진다. 주문의 경우에는 주문의 상태와 이 주문이 어디로 배송되는지에 관련된 정보들이 필요한다. 예를 들어 발신인, 발신인의 정보, 발신인의 연락처, 발신인의 주소, 수신인, 수신인의 연락처, 수신인의 주소 등이 그러한 정보들이다. ◎ 식별자 포함한 속성 구분

논리 디자인(Normalization) 다양한 유형의 검사를 통해 데이터모델을 좀더 구조화하고 개선시켜 나가는 절차에 관련된 이론. 하나의 테이블에는 중복된 데이터가 없도록 하는 것이 원칙이다. 2) 정규화(Normalization) 내용 정규화 정규화 내용 제 1차 정규화 복수의 속성값을 갖는 속성을 분리. 제 2차 정규화 주식별자에 종속적이지 않은 속성의 분리. 부분종속(Partial dependency) 속성을 분리 제 3차 정규화 속성에 종속적인 속성의 분리. 이전종속(Transitive dependency) 속성의 분리. 보이스-코드 정규화 다수의 주식별자 분리. 제 4차 정규화 다가 종속(Multi-Valued Dependency) 속성 분리. 제 5차 정규화 결합종속(Join Dependency)일 경우는 두개 이상의 N개로 분리

논리 디자인(1NF) 1) 제 1정규화(First Normailization Form) 모든 엔티티타입에는 하나의 속성만을 가지고 있어야 하며 반복되는 속성의 집단은 별도의 엔티티타입 으로 분리한다. <정규화 대상 테이블> 주문목록 제품번호 주문번호 제품명 재고수량 수출여부 고객번호 사업자번호 고객우선순위 주문수량

논리 디자인(1NF) 2) 제 1정규화(First Normailization Form) 결과 제품 제품주문 제품번호 제품명 재고수량 제품주문 제품번호(FK) 주문번호 수출여부 고객번호 사업자번호 고객우선순위 주문수량

논리 디자인(2NF) 1) 제 2정규화(Second Normailization Form) 속성중에 주식별자에 종속적이지 않고 주식별자를 구성하는 속성의 일부에 종속적인 속성인 부분 종속 속성(Partial Dependency Attribute)을 분리하는 것. 제품 제품번호 제품명 재고수량 제품주문 2) 제 2정규화(Second Normailization Form) 결과 제품번호(FK) 주문번호(FK) 주문수량 주문 주문번호 수출여부 고객번호 사업자번호 고객우선순위

논리 디자인(3NF) 1) 제 3정규화(Third Normailization Form) 1,2차 정규화를 통해 분리된 테이블에서 속성 중 주식별자에 의해 종속적인 속성 중에서 다시 속성 간에 종속 관계가 발생되는 경우에 3차 정규화를 진행한다. 2) 제 3정규화(Third Normailization Form) 결과 제품 제품번호 제품명 재고수량 제품주문 주문 고객 제품번호(FK) 주문번호(FK) 주문수량 주문번호 고객번호(FK) 주문번호 수출여부 고객번호 사업자번호 고객우선순위

논리 디자인(기타) 1) 보이스-코드 정규화 2) 제 4정규화 3) 역정규화 1,2,3차 정규화는 모두 하나의 주식별자를 가졌을 때를 가정하여 진행지만 만약 하나의 테이블에 여러 개의 식별자가 존재하면 데이터 조작에 문제가 된다. 복잡한 식별자 문제 해결에 사용된다. 2) 제 4정규화 하나의 테이블에 두 개 이상의 독립적인 다가 속성(Multi-Valued Attribute)이 존재하는 경우 다가 종속 (Multi-Valued Dependency)이 발생되어 문제가 발생된다. 이경우 4정규화의 대상이 된다. 3) 역정규화 * 테이블 합치기 : JOIN 질의를 줄이기 위해서 테이블을 합칠 수 있다. * 그룹 합계를 미리 계산해 놓기 : 트리거(Trigger)를 이용해 데이터가 변경될 때마다 주문의 합계를 미리 계산해 놓을 수 있다. * 한 테이블에서 자주 사용하는 레코드와 그렇지 않은 레코드들을 분리시킨다. * 자주 JOIN 질의로 질의되는 컬럼들을 중보해서 저장한다. JOIN 질의를 통해 다른 테이블에 있는 컬럼들을 자주 참조하는 경우에 아예 해당 컬럼들을 테이블에 추가할 수 있다.

물리 디자인 1) 데이터베이스 구축 준비 2) 데이터베이스 구축 관계형 테이블로의 전환 반정규화 무결성 제약 정의 트랜잭션 분석 뷰 설계 인덱스 설계 데이터베이스 용량 설계 접근방법 설계 데이터베이스 분산 설계 2) 데이터베이스 구축 데이터베이스 구축 위한 사전 준비 데이터베이스 생성 테이블스페이스 생성 사용자 및 역할 과 권한 지정 오브젝트 생성 분산 환경 생성