Chapter 5 데이터베이스 도입
5-1 순서의 정리
- 시스템을 도입하는 흐름
1. 시스템 도입 후의 문제와 데이터베이스 도입의 흐름
1) 요건 정의
어떤 시스템을 만들 것인가 결정한다
- 과제 또는 요구사항을 청취하여 어떤 기능이 필요한지 알아낸다.
2) 설계
어떤 테이블과 컬럼을 만들어야 하는지 결정한다
- 요건 정의를 바탕으로 그것을 실현하기 위한 사양을 결정하는 공정
- 데이터베이스는 어떤 테이블과 컬럼을 둘 것인지,
어떤 컬럼에 어떤 타입이나 제약을 둘 것인지를 결정한다.
- ER 다이어그램을 이용하거나, 정규화를 하기도 한다.
3) 개발
설계한 내용을 기반으로 시스템을 만든다
- 설계한 내용을 기초로 소프트웨어나 데이터베이스를 만들어간다.
- 데이터베이스에서는 SQL 언어 등을 이용하여 테이블을 만들고 컬럼에 제약을 설정하게 된다.
4) 전환 / 운용
만들어진 시스템을 사용하기 시작한다
- 완성된 시스템을 업무에 적용하기 위해 전환하거나 소프트웨어를 공개하는 등 운용을 개시
- 운용 전에 기능 테스트를 하거나, 일단 1개 부서만을 대상으로 하는 등 작은 범위에서 시범적으로 시작
5-2 역할 분담: 시스템 도입이 주는 영향
1. 시스템 개발에 필요한 담당자
자체적으로 개발하는 경우,
- 데이터베이스를 설계하는 사람
- 설계를 바탕으로 데이터베이스를 구축하는 사람
- 완성된 시스템을 테스트하는 사람
등의 역할분담이 필요하다.
2. 시스템 도입으로 바뀌는 업무 내용
- 실제로 업무 시스템을 이용하고 있는 구성원에게는 현재 불편한 점 또는 요구사항을 수집하여 새로운 시스템에 그것을 반영할 수 있다.
새로운 시스템을 도입함으로써 업무 프로세스가 바뀌거나, 시스템 이행 시에 업무를 중지하게 되는 때도 생길 수 있으므로, 담당자와 연계하여 진행할 필요가 있다.
5-3 도입의 단점, 도입의 목적
- 데이터베이스를 도입해야만 하는가 검토한다
1. 데이터베이스를 도입했을 때의 단점
-
데이터베이스의 설계나 도입에는 시간과 비용 소요
-
DB를 도입할 때까지는 요건을 정의하고 설계/개발을 하고 운용을 개시하기 위한 조정 작업이 필요하다.
-
전문지식이 필요하게 된다. (SQL을 통한 조작법을 익여햐 한다.)
-
에러가 발생하면 원인을 파악하고 대처하고, 백업이나 보안 대책을 강구할 필요가 있는 경우도 있다.
2. 시스템을 도입해야만 하는지 검토한다
- 데이터베이스는 마법의 도구가 아니라 어디까지나 정보를 축적하거나 정리하기 위한 도구
- 데이터베이스에 의해 목적 달성, 장점이 있는 것인지 등
5-4 요건 정의
- 누가 어떤 목적으로 사용하는지 정리한다
1. 필요한 기능을 알아내는 요건 정의
- 요건정의 : 무엇인가 이루고 싶은 요구사항이 있고 그것을 어떤 식으로 실현할 것인지 정리하는 요건들을 검출하는 작업
요건정의를 수행
- 개발자나 고객(Client) 등 시스템과 관련된 구성원 전원이 현재의 문제점이나 개발하는 기능의 내용, 완성 후 시스템을 조작하는 모습, 업무의 변화를 파악할 수 있어서 회피 가능한 실패들을 미리 방지할 수 있다.
- 결정한 내용은 요구사항정의서란 이름으로 정리하는 경우가 많다.
2. 데이터베이스에서의 요건 정의
-
어떤 데이터를 저장해야 하는지, 어떤 데이터를 출력해야 하는지 등 고려
5-5 엔티티, 속성
-
저장할 필요가 있는 데이터를 생각한다
1. 데이터베이스에 저장하는 항목을 확인한다
-
상품 정보의 어떤 항목을 저장할지 결정해야 한다.
ex) 상품명이나 가격과 같은 상품 자체에 대한 정보 이외에 구입자 정보, 어느 상품을 누가 샀는지 등의 이력데이터베이스에 저장해 두지 않으면 안 되는 정보를 망라해두고, 이후에 진행되는 순서인 테이블 설계에 활용한다.
2. 저장 대상이 되는 것과 그 항목을 추출한다
-
저장해야 할 데이터를 정리하기 위해 저장 대상이 되는 실체(엔티티, Entity)와,
엔티티가 가지는 상세한 항목(속성)을 추출한다. -
엔티티 : 공통된 내용을 가진 대략적인 데이터의 덩어리를 의미 -> 데이터 속에 등장하는 사람이나 물건을 가리킴, 실체
ex) 상품, 구매자, 구매 이력, 점포 등 -
실제로 존재하고 있는 것이 아니어도 되며 구입 이력과 같이 개념적인 것도 포함된다.
-
속성 : 엔티티에서 한층 더 상세한 항목들을 말한다. 상품이 엔티티라면,
ex) 상품명이나 가격, 상품ID 등
5-6 릴레이션십, 1대다, 다대다, 1대1
-
데이터간의 관계를 생각한다
1. 엔티티 간의 관계를 확인한다
-
릴레이션십(Relationship) : 엔티티 간 연결(엔티티는 다른 엔티티와 관계되는 경우가 많다.)
-
릴레이션 형태의 데이터베이스에서는 여러가지 관련된 테이블끼리 조합해 데이터를 표현
미리 엔티티 간의 관례를 생각해 둠으로써 테이블 설계 시 테이블 간의 관계와 필요한 컬럼을 파악하기 쉽게 된다.
2. 관계의 종류
1) 1대 다
하나의 데이터에 대해 여러 데이터가 관련되어 있다는 관계를 나타냄
ex) 한 부서에 여러 직원이 존재, 1명의 사용자에게 여러 개의 게시물이 존재하기 때문에 1대다의 관계2) 다대다
하나의 데이터에 여러 개의 데이터가 관련되어 있으며, 상대방도 이쪽의 여러 데이터와 연결되어 있는 관계
ex) 한 개의 수업에 여러 학생이 수강하고, 반대로 한 명의 학생은 여러 수업을 듣는 것과 같다.3) 1대1
어떤 데이터에 대응하는 하나의 데이터와 연결되는 관계
ex) 사이트에 등록한 사용자 계정과 메일 수신 설정 정보는 1명의 사용자마다 대응하는 정보가 연결된다. -
단 테이블 설계 시에 1:1 관계는 하나의 테이블로 묶일 수 있기 때문에 특수한 경우에 한하여 사용되는 경우가 많다.
5-7 ER 다이어그램
-
데이터 간의 관계를 그림으로 나타낸다
1. 데이터와 그 관계성을 파악하는 수단
-
ER 다이어그램은 엔티티와 관계를 그림으로 나타낸 것.
-
개념모델(추상화) → 논리모델 → 물리모델(구체적)3개의 층으로 나누어 생성한다. -
개념모델 : 더욱 추상화한 그림으로, 시스템의 전체 모습을 넓게 파악
ER 다이어그램을 보는 것만으로 어떤 데이터가 있고 데이터 간에 어떤 관계를 맺고 있는지 한눈에 파악할 수 있다.
😁 도움이 되는 부분
1. 테이블 설계
- ER 다이어그램은
시스템 전체의 로직(logic)이나 업무의 구조, 등장 인물이나 물건을 전체적으로 표현할 수 있다. - 따라서 테이블 설계에 있어서 필요한 요소를 빠뜨리지 않고 결정하는 데 도움이 된다.
2. 문제점 파악
- 데이터베이스에 설계상의 문제가 있을 때
기존의 데이터베이스 전체 모습을 한눈에 파악할 수 있어 문제점을 파악하고 해결방안을 도출하는데 도움을 줄 수 있다.
2. ER 다이어그램을 그리다
- 그림을 그리는 소프트웨어로 작성하여 전자 데이터로 남겨두면 편리하다.
5-8 ER 다이어그램의 표기법
- ER 다이어그램의 표현 방법
1. ER 다이어그램의 기본적인 기술(記述) 방식
-
ER 다이어그램은 엔티티 이름과 그 엔티티가 가진 속성을 묶어 기술하고,
관련된 엔티티들을 선으로 연결하는 것 (한 눈에 파악 가능!) -
이때 관계는 1대다, 다대다, 1대1 중 어떤 종류인지 구별할 수 있도록 해야 한다.
2. ER 다이어그램 표기법의 종류
- INDEF1X 표기법이나 IE 표기법, Barker 표기법 등
- 사전에 적용할 표기법을 정해두는 것이 무난하다.
5-9 개념모델, 논리모델, 물리모델
- ER 다이어그램의 종류
1. ER 다이어그램의 3가지 모델 종류
1) 개념 모델
- 가장 추상적이며 물건(엔티티)이나 현상을 대략적으로 정리하여 데이터베이스에 필요한 요소를 넓게 바라볼 수 있도록 한 그림
2) 논리 모델
- 개념 모델을 기초로 보다 데이터베이스에 저장되는 데이터 형식에 가까운 형태로 상세하게 기술한 그림
- 개념모델에 속성이나 릴레이션십(1대다/다대다/1대1)을 추가해 나간다.
3) 물리 모델
-
ER 다이어그램의 최종 모델로 실제로, 여기서 정리한 내용은 실제로 데이터베이스에 의해 관리 가능한 형식
-
논리 모델을 바탕으로 실제 데이터베이스에서 적용할 테이블이나 컬럼의 이름, 데이터 타입을 정하거나 필요한 경우 중간 관계 테이블(매핑 테이블) 을 설치한다.
-
데이터베이스와 테이블의 이름을 영어와 숫자로 변환하고, 다대다를 표현하기 위해 매핑 테이블을 두었다.
