개체(엔티티)를 추출하고 개체들 간 관계 정의하여 ER - 다이어그램 (ERD)을 만드는 과정 까지를 말함
사각형: 개체, 타원형: 속성, 마름모: 관계, 실선: 개체와 속성, 관계를 연결
개체 관계모델
ERD: 개체 관계 모델의 약어로 데이터베이스의 구조를 엔티티와 관계로 도식화하는 기법 중 하나
논리적 모델링; 회원번호 물리적 모델링: no
엔티티: 테이블, 속성: 컬럼(열), 튜플: 레코드(행)
개체: 명사형으로 지정, 실세계의 기본적인 표현을 할 수 있는 항목, 인스턴스의 집합
속성: 성질이나 상태, 개체가 가질 수 있는 세부적인 특성, 데이터의 가장 작은 논리적인 단위로서 속성값은 더 분해하려 해도 분해할 수 없는 원자값만을 갖는다. 물리적 모델링 과정에서 칼럼이 된다.
도메인: 하나의 속성에 나타날 수 있는 값들의 집합
인스턴스: 개체의 구체적인 하나의 예, 데이터 형식을 확인할 수 있음, 데이터 한칸 한칸.
기본키: 인스턴스들을 서로 구별할 수 있는 유일한 값을 갖는 속성. ERD에서 기본키가 되는 속성에 밑줄로 표시
관계: 개체간의 연관성을 나타내며 요구 사항 명세서에서 동사형으로 표현
레코드: 인스턴스 한줄
ER모델에서 개체간의 관계
1:1(One To One): 두 개체를 하나의 테이블로 통합
일대일 실선에 1
1:N(One To Many): 주종관계를 알아야한다. 일반적으로 일에 해당하는 테이블이 부모테이블이고 다에 해당되는 테이블이 자식 테이블이다. 부모 테이블의 기본 키를 자식 테이블에 포함시키고 외래 키로 설정, 외래키 잡을 때 컬럼명은 다를 수 있지만 자료형은 반드시 같아야한다.(값을 참조하니까)
일대 다 실선에 N
N:M(Many To Many): 다대다 관계에 대한 테이블을 따로 만든다. 관계에 의해 생성된 테이블을 두 개체가 갖고 있던 기본키를 외래키로 설정. 관계에 의한 테이블의 기본키를 만드는 방법은 두 가지 있다.
1. 두 외래키를 조합하여 기본키로 설정
2. 새로운 필드를 추가하여 기본 키로 설정
여러명 대 여러명
실선에 각각 N, M
논리적 모델 및 물리적 모델
개념적 모델링에서 만든 ER 다이어그램을 사용하려는 DBMS에 맞게 매핑하여 실제 데이터베이스로 구현하기 위한 모델을 만드는 과정
개념적 모델링
약속된 도형으로 만듦
논리적 모델링 과정
상세 속성들을 모두 추출
정규화 수행
데이터 표준화 수행
물리적 모델
논리적 모델을 실제 컴퓨터의 저장 장치에 저장하기 위한 물리적 구조 정의, 구현
DBMS 특성에 맞게 저장 구조를 정의해야 데이터베이스가 최적의 성능을 낼 수 있다.
실제 사용할 테이블, 컬럼 명
설계단계에서 논리적, 물리적 데이터베이스를 설계한다.
IE표기법에서 관계는 점선으로 표기
-강한 개체 타입은 직원 개체 타입의 직원번호와 같이 각 개체를 식별할 수 있는 기본키를 가진다.
강한 개체: 다른 개체의 도움 없이 독자적으로 존재할 수 있는 개체
약한 개체 타입: 독립적인 키로는 존재할 수 없지만 상위 개체 타입의 키와 결합하여 약한 개체 타입의 개별 개체를 고유하게 식별하는 속성을 식별자 관계로 표현하는데 실선으로 표기함
약한 개체: 독자적으로는 존재할 수 없고 반드시 상위 개체 타입을 가짐
테이블 명세: 물리적인 모델링 과정에서 엔티티는 테이블이 되고 속성은 칼럼이 된다.
SQLDevelope 에서 보기 DataModeler 브라우저
논리적 모델링 오른쪽 클릭 표시
기본UID는 기본키
관계설정 시 부모 테이블 먼저 선택
소스기수 : 부모 엔티티
대상기수: 자식 엔티티
소스 선택 사항; 부모 엔티티의 튜플에 대응하는 자식 엔티티의 튜플이 없을 수도 있음.
대상 선택 사항: 자식 엔티티의 튜플에 대응하는 부모 엔티티는 반드시 존재
RESTRICT: 참조 무결성 처리 규칙
관계 : 두 엔티티 간의 업무적인 연관성
식별 관계: 부모 테이블의 기본 키가 자식 테이블의 기본 키 혹은 후보 키 그룹의 구성원이 된다.
비식별 관계: 부모 테이블의 기본 키가 자식 테이블의 일반 칼럼이 된다.
논리적 ERD를 물리적 ERD로 복사
브라우저 창에서 논리적 모델 항목에서 관계형 모델로 엔지니어링을 선택
테이블 명세서 작성
영어로 변경: 엔티티 이름, 속성 이름, 주식별자(기본키) 이름, 외래 식별자(외래키) 이름
VARCHAR2, NUMBER => VARCHAR, DECIMAL을 선택 하면 변환되어 ERD에 표시
정규화: 데이터 모델을 보다 효율적으로 개선시켜나가는 과정, 데이터베이스에 저장되는 데이터 중복의 최소화하기 위해 서로 독립적인 관계는 별개의 테이블로 표현한다는 것
제 1 정규화
반복되는 속성들을 다른 개체 (테이블)로 나누어 분리하는 작업
또 다른 개체로 판단할 수 있는 속성들을 분리하고, 각 객체 속성들의 유일한 식별자를 갖게된다. 부모 테이블의 식별자는 자식 테이블의 외부키와 연결된다.
모든 속성은 반드시 하나의 값을 가져야한다.(반복 형태가 있어서는 안된다.)
정규화가 이루어지고 나면 자식 엔티티로 분리된다.
제 2정규화
모든 속성은 식별자에 직접적으로 의존적이어야 하며 이에 해당되지 않는 속성을 분리한다.
모든 속성은 반드시 UID 전부에 종속되어야 한다. (UID 일부에만 종속되어져서는 안된다.)
데이터 모델링: 데이터베이스를 새롭게 구축하기 위한 준비과정, 요구사항을 듣고 사용자 관점을 분석하여 추상화하여 문서화하는 과정
관리: 등록, 수정, 삭제, 조회를 뜻함 > 이를 위해 데이터베이스 설계가 필요
계획 > 분석 > 설계 > 구축
계획: 세부 추진일정 수립, 인터뷰 계획(현업 담당자와 개발자 간에 , 자료수집 계획(요구분석 및 입출력 장표수립), 요구 분석 자료 만들어짐
분석: 정표와 인터뷰 자료 등 수립된 자료를 바탕으로 DATA분석, 개념적 데이터 모델링 및 ERD 작성, 만들어진 사이트의 장점과 단점을 분석하고 벤치마킹
설계: ERD를 기반으로 테이블 설계서 작성, 물리적 구조 설계(필드명 정하기 끝나면 바로 만들어도 O), 화면 설계서 작성
구축: 테이블 설계서를 기반으로 테이블 생성, 화면 설계서를 기반으로 프로그램 코딩(VB,PB, MFC 등)
계획
요구사항 분석: 사용자의 요구사항을 간단하게 기술, 필요한 항목, 어떤 내용이 저장되어야만 하는지, 테이블, 완벽할 수는 없지만 전체가 바뀌면 안된다. EX) 우리 사이트에서 저장된 데이터는 5년 동안 저장됩니다, 게시판이면 게시판에 관련된 모든 업무를 맡아야함. 요구분석부터 마지막까지 만들면서 통합 OR 같이 만들자. 온전하게 한 사람이 CRUD가 되어야함.
일정 정리: 오늘은 여기까지 하고 반드시 여기까지 끝내야해
사용자의 요구 등을 정리 및 분석
- 사용자 식별
- 데이터 베이스 용도 식별
- 사용자 요구 사항 수집 및 명세
유스케이스 다이어그램
유스케이스: 말 그대로 풀어보면 "사용 사례"로서 시스템이 어떻게 사용될지에 대해 표준화된 규칙에 따라 다이어그램으로 표현한 것이다. 고객과 개발자는 표준화된 규칙만 이해하고 있다면, 유스케이스 다이어그램을 통해 시스템의 기능이나 상호 작용 등을 쉽게 이해할 수 있다.
유스케이스를 이용한 요구사항 분석 방법: 통일된 규칙으로 시스템을 표현하고, 이를 통해 고객 및 사용자, 개발자의 다양한 관점을 찾아내어 그 간격을 조정하는 것. 이러한 유스케이스 기반의 요구사항 분석은 시스템을 가시화시켜 주는 모델링 기법인 UML을 이용.
1.UML: 요구사항의 추출부터 분석, 명세를 통하여 생성되는 산출물들을 표준화된 다이어그램으로 연결시킴으로써, 고객 및 사용자, 개발팀의 다양한 관점을 다룰 수 있는 효과적인 도구
정의: 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어로 소프트웨어 개념을 다이어그램으로 그리기 위해 사용하는 시각적인 표기법
필요성:
1. 시스템의 구조적 문제와 프로젝트 팀내의 의사 소통
2. 대규모 프로젝트 구조의 로드맵을 만들 때 유용하다.
3. 개발할 시스템 구축에 대한 기초를 마련할 수 있다.
4. 유지보수를 위한 설계의 back-end 문서
2.유스케이스 다이어 그램: 사용자 관점에서 시스템의 서비스와 기능 및 그와 관련된 외부 요소를 보여주는 다이어그램이다. 고객과 개발자는 이 다이어그램을 보며 요구사항에 대한 의견을 조율
시스템: 만들고자 하는 시스템의 범위를 뜻한다. 시스템을 표현하기 위해서는 유스케이스를 둘러싼 사각형의 틀, 시스템 명칭을 사각형 안쪽 상단에 기술
액터: 시스템의 외부에 있으면서 시스템과 상호작용하는사람 또는 다른 시스템, 사람모양, 액터명=액터의 역할
유스케이스: 시스템이 액터에게 제공해야하는 기능의 집합. 시스템의 요구사항을 보여줌. 타원. 동사로 표현. 유스케이ㅣ스 하나가 개발될 기능 하나와 연결될 수 있도록한다.
관계: 시스템의 요구사항을 액터와 유스케이스 간에 상호작용이 존재함을 나타냄. 연관관계로 나타낼 때 액터와 유스케이스 사이에 실선을 연결하여 표현 / 유스케이스-유스케이스: 실선X, 점선
포함관계: 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계. 포함되는 유스케이스는 포함하는 유스케이스를 실행하기 위해서는 "로그인을 한다" 라는 유스케이스가 먼저 실행되어야 하므로 포함관계 표시
포함하는 유스케이스에서 포함되는 유스케이스 방향으로 화살표를 점선으로 연결 표현 <<include>> / 유스케이스 사이의 상호작용
확장관계: 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성되는 관계. 하나의 유스케이스가 실행될 때 포함 관계에 있는 유스케이스가 특정 상황에서만 실행된다는 뜻. ex) 파일 첨부기능 > 글을 등록한다라는 유스케이스는 확장 대상 유스케이스가 되고 파일을 첨부한다라는 유스케이스는 확장 기능 유스케이스.
확장 기능 유스케이스에서 확장 대상 유스케이스 방향으로 화살표를 점선으로 연결 표현. <<extend>> 표현
일반화 관계; 유사한 유스케이스들 또는 액터들을 모아 그들을 추상화(주어진 문제나 시스템을 중요하고 관계있는 부분만 분리해 내어 간결하고 이해하기 쉽게 만드는 작업.)한 유스케이스 또는 액터와 연결시켜 그룹핑함으로써 이해도를 높이기 위한 관계. 구체적인 유스케이스에서 추상적인 유스케이스 방향으로 끝부분이 비어져 있는 삼각형 테두리로 표현된 화살표를 실선으로 연결하여 표현
유스케이스 다이어그램 작성: 개발하고자 하는 시스템을 유스케이스 다이어그램으로 표현하는 것을 유스케이스 모델링
-사용자 식별, 외부 시스템 식별, 표현 대상인지 아닌지.
-액터가 요구하는 서비스 식별, 정보 식별, 액터가 시스템과 상호 작용하는 행위 식별
-액터와 유스케이스 간의 연관관계 정의, 유스케이스 간 포함, 확장 관계 정의, 액터 간, 유스케이스 간의 일반화 정의
회원등록을 할 때에는 반드시(포함관계) 실명확인을 한다.
유스케이스 기술서
유스케이스 이름, 액터명, 유스케이스 개요 및 설명, 사전 및 사후 조건, 작업 흐름, 시나리오
작업흐름
-정상흐름: 해당 유스케이스가 정상적으로 수행되는 흐름
-대안 흐름: 유스케이스 내의 작업 흐름이 수행되는 중에 특정 시점에서 여러 가지 선택적인 흐름으로 나뉘어 질 경우에 발생하는 흐름.
- 예외 흐름: 유스케이스 내의 작업 흐름이 수행되는 중에 발생할 수 있는 예외상황이나 오류를 표현하는 흐름.
• 유스케이스명: 글을 등록한다.
• 액터명: 사용자
• 유스케이스 개요 및 설명
- 사용자는 원하는 글을 게시판을 등록한다.
• 사전 조건: 로그인한다.
• 작업 흐름
- 정상 흐름(Normal Flow)
1. 사용자는 글쓰기 버튼을 클릭한다
2. 시스템은 글쓰기 화면을 실행한다.
3. 사용자는 글쓰기 화면에서 원하는 글을 작성한다.
4. 사용자는 등록버튼을 클릭한다
5. 시스템은 글을 데이터베이스 게시판 테이블에 저장한다.
- 대안 흐름(Alternative Flow):
1. 정상흐름4에서 등록 취소버튼을 선택할 경우, 시스템을 게시판 목록 조회 화면을 보여준다
- 예외 흐름(Exception Flow)
1. 정상흐름3에서 글쓰기 화면에서 글을 쓰지 않고 등록 버튼을 클릭할 경우, 시스템은 “내용을 입력해 주세요”라는 경고 메시지를 보여준다.
요구사항 정의서
요구사항들의 목록화를 통해 전체적인 요구사항의 리스트를 확인
리스트를 확인하는 문서, 자세한 내용은 명세서를 확인 / 요구사항 ID는 모든 산출물 문서에 표시해야함, 중복되지 않게 작성