[소프트웨어분석및설계🛠️] 11장 데이터베이스와 UI 설계

출처 : 강의 교안, 시스템분석설계 with 애자일 (생능출판사, 최은만)

 

1. 데이터베이스 설계

1.0  데이터베이스 설계

1) 저장 매커니즘

- 자료의 저장

• 정보시스템의 주된 요구사항
• 시간이 흘러도 변하지 않고 최소의 중복성을 가지는 안정적인 구조

- 파일시스템 vs. 데이터베이스 ➡️ 대부분의 정보시스템은 자료를 저장하기 위해 데이터베이스 시스템을 사용

• 파일 시스템은 디렉토리와 파일로 구성
• 파일의 구성 : 연속구조, 순차 구조, 랜덤 구조
• 접근 방식 : 순차 접근, 인덱스 순차 접근, 직접접근

- 파일 시스템의 문제

• 데이터 파일들에 중복된 데이터 존재, 데이터 간의 불일치
• 데이터의 공유가 부족 ; 새로운 프로그램 개발을 위해 새롭게 파일 구성
• 응용프로그램과 데이터 간의 독립성이 없음 ;  유지보수 비용이 증가
• 데이터 보안 미흡
• 데이터 회복의 어려움

 

1.1 관계형 데이터베이스 모델

1) 관계형 데이터베이스

- 논리적 모델 :  DB 사용자에 대한 뷰 제공

- 파일구조 : DB에 효율적인 파일 구조

- 기본 파일 시스템 운영체제가 제공하는 파일 시스템

 

2) DBMS(DB Management System)

- DB와 사용자 사이에 인터페이스 제공

- DBMS의 요소

• 사용자 : 질의나 스위치 보드 명령으로 자료를 접근
• 데이터베이스 관리자 : 데이터베이스 관리와 지원
• 데이터 조작 언어 : 저장, 탐색, 갱신, 삭제 등을 제어
• 스키마 : 필드와 테이블, 관례를 기술한 정의
• 물리적 저장소 : 모든 데이터 요소를 저장

3) DB 설계 프로세스

(1) 논리적 설계(logical design)

- 개념적 데이터 모델에 기반을 바탕으로 수행

- 4가지의 주요 단계들

• 정규화 이론을 활용하여 UI(양식과 리포트) 각각에 대한 논리적 데이터 모델을 작성
• 모든 UI들을 기반으로 설계된 정규화된 데이터 요구사항을 하나의 논리적 DB 모델로 통합
• UI에 대한 명확한 고려 없이 개발된 개념적 E-R 데이터 모델을 정규화된 데이터 요구사항으로 변환
• 통합된 논리적 DB 설계를 변환된 E-R 모델과 비교하여 하나의 최종적인 논리적 DB 모델을 작성

(2) 물리적 설계(physical design)

- 논리적 설계의 결과물을 바탕으로 수행

- 설계를 위한 주요 의사결정

• 논리적 DB 모델에 나타난 각각의 속성들에 대한 저장 형식(data type)을 결정
• 논리적 DB 모델의 속성들을 물리적 레코드들로 grouping
• 파일구성
• 보다 효율적인 데이터 접근을 가능케 하는 데이터 저장 매체와 구조를 결정

 

4) 산출물

- 논리적 DB 설계는 모든 데이터 요소들과 시스템의 입력물/산출물 양식, 보고서 및 ER모델을 고려해야 함

- 주요 산출물 : 정규화된 관계들

• 기본키(primary key) : 관계(relation)의 모든 발생 건들에 있어 해당 값이 유일한 속성 

- 관계들은 컴퓨터 파일들에 대응되지 않음

- 물리적 DB 설계를 통해 관계들을 파일로 변환

 

5) 관계형 데이터 모델 ➡️ 연관된 테이블들 또는 관계들의 집합으로 데이터를 표현함

(1) 기본 용어

- 엔티티 : 데이터로 모아 보관하는 단위(사람, 장소등)

- 테이블 : 관련된 레코드의 묶음

- 필드 : 엔티티에 대한 특징 또는 사실

- 레코드 : 관련된 필드의 집합(튜플)

- 기본키 : 엔티티의 특정한 멤버를 구별하기 위한 필드

- 후보키 : 기본키로 선정될 수 있는 후보

- 외부 키 : 테이블 사이의 관계를 나타내기 위한 필드

- 보조 키 : 접근하거나 탐색하는 데 사용될 수 있는 필드의 조합

 

(2) 관계(Relation)

- 2차원으로 구성되고 이름을 가지는 데이터 테이블

- 하나의 관계는 이름이 있는 열(column)들과 이름이 붙여지지 않은 임의의 개수의 행(row)들로 구성

- 특성

• 하나의 값만 셀에 입력됨
• 열에 입력되는 값들은 동일한 형태를 가짐
• 각 행은 고유함 ; 주키의 값이 고유성을 보장
• 열의 순서는 관계의 의미나 활용의 변경 없이 교체될 수 있음
• 행들은 순서에 상관 없이 교체되거나 저장될 수 있음

- 잘 구조화된 관계(well-structured relation)

: 데이터의 중복이 최소화되고 사용자가 오류나 불일치 없이 행을 삽입, 수정, 삭제할 수 있는 관계

 

1.2 정규화 (Normalization)

1) 정규화

- 복잡한 데이터 구조를 단순하고 안정적인 데이터 구조로 변환하는 과정

• DB에 있는 각테이블에 필드와 속성을 배정하여 테이블을 설계하는 과정 (재구성을 통한 구조화 과정)
• 단순하고 융통성 있는 중복 없는 DB 설계
• 3차 정규형이 목표

- 정규화 과정

• 비정규형 ➡️ 1차 정규형 ➡️ 2차 정규형 ➡️ 3차 정규형
• 정규화는 함수적 종속성이론에 근거

2) 함수적 종속성(functional dependency)

- 어떤 관계에서 속성 A의 모든 값이 속성 B의 값들을 고유하게 결정하는 경우, 속성 B는 속성 A에 대해 함수적으로 종속된다.

- 속성 A에 대한 속성 B의 함수적 종속성은 A->B로 표현

 

3) 1차 정규형

- 반복그룹이 포함되어 있지 않은 테이블

- 모든 속성들이 원자값을 가짐

- 비정규형 테이블의 기본키를 확장하여 반복 그룹의 기본키를 포함시킴

 

4) 2차 정규형(second normal form, 2NF)

- 기본키를 제외한 모든 다른 속성들은 기본키 전체에 의해 규정됨 ; 완전 함수적 종속(full functional dependency)

- 1차 정규형에서 기본키를 제외한 모든 속성들이 기본키에 의해 종속되는가를 확인

- 2차 정규형으로 만들기

1. 현재 기본키 필드마다 별도의 테이블을 만들고 명명
2. 원래 기본키 필드의 조합에 대한 새로운 테이블 생성
3. 각 테이블에 각 필드를 배정

5) 3차 정규형(third normal form, 3NF)

- 기본키 이외 모든 속성들은 단지 기본키에만 종속

- 3차 정규형으로 만들기 위해서 2차 정규형 테이블에서 기본키가 아닌 다른 필드에 종속되어 있는 모든 필드를 삭제해서 새로운 테이블에 넣어야 함

- 정규화 결과, 기본키가 아닌 모든 속성들은 기본키 전체에만 의존하게 됨

 

1.3 ERD 관계로 변환하기

1) ERD

- ERD : 정규화된 관계들로 변환하기에 유용한 개념적 모델

- 변환 단계

1. 개체 표현
2. 관계성 표현
3. 관계 정규화
4. 관계 결합

2) 개체 표현

- 개체는 각각 관계로 변환됨

- 개체의 식별자는 대응되는 관계의 기본키가 됨

- 기본키는 다음과 같은 2가지 성질을 만족해야 함

• 키의 값은 관계의 모든 행을 고유하게 정의해야 한다
• 키가 중복되어선 안 된다

3) 관계성 표현

- 이진 1:N 관계성

• 일(1)쪽 관계의 기본키 속성(또는 속성들)을 다(N)쪽 관계의 끝 열에다 외래키로 추가함

- 이진 또는 일진 1:1

• 가능한 3가지 방법
  • A의 기본키를 B의 외래키로 추가
  • B의 기본키를 A의 외래키로 추가
  • 앞의 사항 모두

- 이진 및 그 이상의 차수에 대한 M:N 관계성

• 새로운 관계를 만들고 관련된 관계들의 기본키들을 새로운 관계의 기본키로 설정함

 - 일진 1:N 관계성

• 순환외래키(recursive foreign key) 활용
• 순환외래키(recursive foreign key)  : 같은 관계 내에서 기본키 값을 참조하는 외래키

- 일진 M:N 관계성

• 별도의 새로운 관계를 생성함
• 새로운 관계의 기본키는 같은 기본키의 값들을 취하는 2개의 서로 다른 이름을 갖는 속성으로 구성

 

1.4 관계 결합

- 뷰통합(view integration)

• 논리적 DB 설계의 마지막 과정
• 목적 : 중복된 관계들을 제거하는 것
• 뷰통합과 관련된 문제들
  • 이음동의어(synonyms) :같은 속성에 서로 다르게 붙여진 이름
  • 동음이의어(homonyms) : 의미는 다르지만 서로 같은 이름으로 불려지는 속성들
  • 키가 아닌 속성들 간의 종속성 : 뷰통합의 결과로 종속성이 발생하면 정규화

 

1.5 물리적 파일과 데이터베이스 설계

- 필요한 정보

• 정규화된 관계들과 저장 용량 추정치
• 각 속성들에 대한 정의들
• 데이터가 사용되는 장소와 시간에 대한 설명들
• 응답 시간과 데이터 무결성에 대한 기대수준 또는 요구사항
• 파일과 DB 구현에 사용되는 기술들에 대한 설명
• 물리적 파일과 DB 설계를 위해 상향식 접근
  • 물리적 설계 단계에서는 논리적 데이터모델의 속성 각각에 대한 물리적 필드 설계부터 시작

 

1.6 필드 설계

- 필드(field)

• SW에 의해 인식되는 응용 데이터의 최소 단위
• 관계의 속성 각각은 하나 또는 그 이상의 필드가 됨

 

- Data type 결정

• data type : 시스템SW에 의해 인식되는 코딩 형식
• 4가지 목적
  • 저장 공간의 최소화
  • 필드의 모든 값들에 대한 표현 가능
  • 데이터 무결성 증진
  • 필드의 모든 데이터에 대한 작업(또는 조작) 지원
• 연산필드(calculated fields) : DB의 다른 필드로부터 파생될 수 있는 필드

 

1.7 물리적 테이블 설계

- 하나의 관계형 데이터베이스는 관련 테이블들의 집합

- 물리적 테이블(physical table) 초점

• 행과 이름 붙여진 필드들로 구성된 테이블

- 설계 초점

• 보조 저장장치(저장 공간)의 효율적 활용
• 효율적인 데이터 처리 설계

- 비정규화

• 정규화된 관계들을 물리적 테이블들로 분할하거나 결합하는 과정
• 다른 부분에 있어 불합리한 특성이 발생되더라도 어떤 특정 처리들을 최적화하는 것이 중요할 때 수행함
• 비정규화가 사용될 수 있는 일반적인 경우들
  • 2개의 개체가 일대일 관계성을 가질 때
  • 키가 아닌 속성을 가지는 다대다 관계성이 있을 때
  • 참조 데이터가 있을 때

- 테이블 행들의 배열

• 물리적 파일(physical file)
  • 보조 기억장치에 연이어 저장된 테이블 행들의 집합

• 하나의 테이블이 하나의 파일이 되거나 또는 데이터베이스 전체가 하나의 파일이 될 수 있는데, 이는 사용되는 데이터베이스관리 소프트웨어에 따라 달라짐
• 파일 구성 : 테이블의 레코드들을 물리적으로 정렬하는 기법
  • 빠른 조회, 처리 효율성, 공간의 효율적 사용, 데이터 손실에 대한 보호, 데이터 증가에 대한 대비, 보안 등

• 파일 구성(file organization)
  • OS가 파일의 레코드들을 물리적으로 정렬하는 방식
  • 파일 구성 유형
    • 순차형(sequential) : 파일의 레코드 행이 기본키의 값에 따라 순차적으로 저장
    • 인덱스형(indexed) : 프로그램들이 각 행을 찾을 수 있도록 인덱스가 생성
    • 해시형(hashed) : 각 행의 주소가 기본키 값을 행의 주소로 변환시키는 알고리즘에 의해 결정

- 파일 통제 설계 : 백업기법, 데이터 보안 기법

• 데이터 손실/손상 방지, 인가되지 않은 사용에 대한 보안성 확보
• 백업 기법
  • 파일에 대한 주기적 백업 복사본, 변경사항 로그
  • 트랜잭션 로그 또는 감사 추적용 파일 복사본 저장
• 데이터 보안 기법
  • 코딩, 또는 암호화, 사용자 계정 관리
  • 사용자들이 인증체크 한 후에만 복사본 가지고 일하도록

 

2. UI 설계

2.1 UI 설계

- Shneiderman과 Plaisant의 UI 설계 원칙

• 일관성
• 적절한 사용자 지원
• 적당한 피드백
• 최소의 사용자 입력
• 간편한 오류 처리

- 사용자 중심의 설계

• 배경 지식의 이해
• 그래픽 효과의 극대화
• 이해하기 쉬운 인터페이스
• 프로토타입의 사용
• 사용자에 대한 이해
• 지속적인 피드백

- 정보 시스템의 요소

• Model(자료), View(UI), Control(처리)
• 기능을 사용자에게 보여주는 외관
• 화면과 인쇄물

- 설계 과정

: UI 요구 파악 및 기획 ➡️ 화면, 인쇄물 레이아웃 설계 ➡️화면 흐름 설계

 

2.2 UI 요구 파악

- UI/UX 모델링 기법

• 페르소나(Persona)
  • 어떤 제품 혹은 서비스를 사용할 만한 목표 집단 안에 있는 다양한 유형들을 대표하는 가상의 사용자
  • 경험이 동일한 사용자들을 묶은 후 가상의 인물로 정의
• Journey Map
  • 개별 페르소나들이 제품 이용 흐름에 따라서 어떤 경험의 변화를 보이는지 시각화 시키는 작업
  • 사용자 경험의 척도를 만족도 기준으로 각 stage별로 이용의 흐름을 선형적으로 나열한 방식을 취함
• Elito Method
  • 발견된 주요 사실(key findings)를 가지고 그 의미와 사용자에게 제공할 가치, 구체적인 해결책을 같이 고민
• Affinity Diagram
  • 인터뷰 등 필드 리서치 결과를 아래에서 위로 묶어 나가면서 개별 결과에서는 보이지 않던 가치를 찾음

 

2.3 화면 레이아웃 설계

- 스토리보드(Story Board)

• 와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서
• 와이어프레임 : 화면단위의 레이아웃 설계 작업
• 스토리보드 툴 : 파워포인트, 키노트, 스케치 등