컴알못의 데이터베이스 공부 (데이터베이스 설계)

데이터베이스 설계

데이터베이스 모델링

데이터베이스 구조를 직관적으로 설계하는 건 아주 어려운 일입니다.

현실세계의 데이터는 끊임없이 변화하며 이 변화를 자연스럽게 반영할 수 있는 데이터베이스 구조를 생성하는 건 어려운 일입니다.

그렇기 때문에 데이터베이스 구조의 설계는 데이터베이스 모델링이라고 하는 절차적인 단계를 밟아서 이루어져야합니다.

 

데이터베이스 모델링은 개념적 모델링, 논리적 모델링, 물리적 모델링의 3단계를 나뉩니다.

그리고 데이터 모델이란 데이터 모델링을 위한 도구입니다.

이 또한 개념적 모델, 논리적 모델, 물리적 모델로 나뉩니다.

• 개념적 모델링 - 사용자의 요구 사항을 반영하는데 중점을 둡니다. 그렇기에 분석 관점에서 주로 사용합니다. 대표적으로 E-R 모델이라는 도구를 사용합니다. 이러한 개념적 모델은 논리적 모델로 변환시킬 수 있습니다. 
• 논리적 모델링 - 설계의 관점에서 개념적 모델을 변환하여 표현합니다. 설계의 관점이기 때문에 특정 유형의 DBMS를 염두에 두고 설계됩니다. 관계형 데이터베이스라면 자연스럽게 관계형 데이터베이스를 위한 논리적 구조를 명세하게 되지만, 이건 유형의 이야기지 특정 DBMS를 전용으로한 논리적 모델이 만들어진다는 의미는 아닙니다. 논리적 모델은 DBMS 독립적입니다.
• 물리적 모델링 - 특정 DBMS에 적합한 물리적 구조를 명세합니다. 그렇기에 DBMS 독립적은 아닙니다. 특정한 DBMS를 선택해 거기에 최적화된 레코드 형식과 저장구조, 접근 방식 등을 명세합니다.

데이터베이스 설계 과정

데이베이스 시스템과 사용자는 서로 영향을 주고 받기 때문에 한번에 좋은 설계를 하는 건 어렵습니다.

단계적으로 접근하는 자세가 필요해요.

보통은 5단계의 과정을 거쳐서 진행합니다.

1. 요수사항 분석 - 데이터베이스 사용자로부터 요구사항을 수집하여 요구사항 명세서를 작성하는 단계. 수집한 요구사항을 분석하여 데이터베이스의 구축 범위를 결정짓습니다. 사용자와의 커뮤니케이션 수단으로 인터뷰나 설문 조사 문석 분석을 수행할 수 있겠죠.
2. 개념적 설계 - 사용자의 요구사항을 개념적 데이터 모델로 표현하는 단계. 관계형 데이터베이스 모델이라면 E-R 모델을 설계하는 과정이 됩니다. 개념적 스키마를 완성하는 단계입니다.
3. 논리적 설계 - 개념적 스키마를 참고하여 DBMS의 유형을 선택하고, 논리적 스키마로 변환합니다. 정규화 같은 과정도 이 단계에서 수행됩니다.
4. 물리적 설계 - 사용할 DBMS의 특성을 고려하여 논리적 스키마를 구현할 데이터베이스의 내부 저장 구조와 접근 기법 등을 결정하는 단계. 뷰나 인덱스를 결정하는 것도 이 단계에서 수행. 최종적으로 튜닝 등을 통하여 효율적인 저장 공간과 처리 능력을 최대화.
5. 구현 - 완성된 물리적 데이터베이스 스키마를 실제로 구현. SQL 명령문들을 통해 실제 데이터베이스를 생성.

데이터베이스 모델링이 분석에 초점을 맞췄다면 설계는 구현에 초점을 맞춰 시스템의 구축 과정을 표현합니다.

 

요구사항 분석

결과물 - 요구사항 명세서

목적 - 구축하고자 하는 데이터베이스의 구현범위와 사용자의 범주를 결정

하는 일 - 예비 사용자들로부터 요구사항을 수집하고 필요한 데이터가 뭔지를 분석

방법 - 인터뷰, 설문지 조사, 업무 관련 문서 검토, 기존 시스템이나 유사 시스템에 대한 분석 등등

 

개념적 설계

결과물 - E-R 다이어그램 (관계형 데이터베이스의 경우)

목적 - 데이터베이스 설계의 전체 골격을 결정

하는 일 -

    개체 정의 (개체의 속성을 정의, 키 속성을 지정)

    => 관계 정의 (관계의 속성을 정의, 관계 카디널리티 설정)

    => E-R 다이어그램 완성

- 개체 정의

먼저 요구사항 명세서를 보고 필요한 개체를 도출합니다.

그리고 불필요한 개체가 있다면 제거합니다.

개체를 도출하는 팁은 아래와 같습니다.

명세서 문장 중에서 주어나 목적어로 표현되는 명사들을 찾는다. 속성에 해당하는 하위 개념의 명사들로부터 꾸밈을 받는 상위 개념의 명사를 찾는다. 개체는 관계와 비교하면 상대적으로 오랜 시간 지속되는 특성이 있다. 개체는 보통 또 다른 여러 개체들이 공유하는 대상이다.

- 관계 정의

관계는 개체 간의 연광성을 찾습니다.

관계는 무조건 개체와 개체 사이의 연관성이어야 합니다. 속성이 관계의 대상이 되어선 안됩니다.

연관성의 대상이 개체와 관계라면 요구사항 명세에 오류가 있을 가능성도 있습니다.

관계를 도출하는 팁은 아래와 같습니다.

명세서 문장 중에서 서술어로 표현되는 동사를 찾는다. 관계는 반드시 연관성을 띄는 둘 이상의 개체가 필요하다. 관계는 종속적인 개념이므로 보통 속성으로 고유한 명칭(이름, 코드 등)을 갖지 않는다. 관계는 개체와 비교하면 일시적이며 상대적으로 짧은 시간만 지속됩니다.

- 속성 정의

개체나 관계가 모두 정의되면, 도출된 개체와 관계를 명확하게 하는 속성을 정의합니다.

속성을 도출하는 팁은 아래와 같습니다.

명세서 문장 중에서 주어나 목적어, 서술어를 수식하거나 꾸며주는 명사들을 찾는다. 상위 개념의 동사를 꾸며주는 하위 개념의 명사가 주로 속성이 된다. 속성은 실제 값을 저장한다. 속성은 종속적 개념이므로 상위 개념이 반드시 필요하다.

 

논리적 설계

논리적 스키마를 생성하는 단계.

관계형 데이터베이스라면 릴레이션들로 구성된 논리적 스키마를 정의합니다.

 

개체와 관계로 정의된 개념적 스키마를 릴레이션으로 구성된 논리적 스키마로 변형하는 과정에서 나름의 변환 규칙이 있습니다.

- 개체 변환

개체는 기본적으로 하나의 릴레이션으로 변환됩니다.

릴레이션의 키 속성이나 일반 속성은 개념 스키마의 개체의 키 속성과 일반 속성에 그대로 반영됩니다.

- 관계 변환

개념적 스키마의 관계를 논리적 스키마로 변환하는 규칙은 관계 카디널러티에 따라서 다릅니다.

 

일대다 변환의 경우

이 경우엔 두 개체가 식별 관계인지 비식별 관계인지에 따라 다릅니다.

먼저 식별 관계라는 건 부모테이블로부터 받아온 외래키가 자식테이블에서 기본키로 쓰이는 경우를 말합니다.

반대로 비식별 관계라는 건 부모테이블로부터 받아온 외래키가 그냥 일반 속성으로 쓰이는 경우를 말하고요.

 

식별 관계인 경우 변환 규칙은 다음과 같습니다.

관계 자체는 하나의 외래키 속성으로 변환.

일측 개체 릴레이션의 기본키 속성을 가져와 다측 개체 릴레이션에 외래키 속성으로 추가.

관계가 갖고 있던 모든 속성들도 외래키를 추가한 다측 개체 릴레이션의 속성으로 함께 변환.

약개체는 기본키를 가지지 못하고 외래키를 다측 개체 릴레이션의 부분키와 조합하여 기본키로 지정.

 

비식별 관계인 경우 변환 규칙은 다음과 같습니다.

관계 자체는 하나의 외래키 속성으로 변환.

일측 개체 릴레이션의 기본키 속성을 가져와 다측 개체 릴레이션의 외래키 속성으로 추가.

관계가 갖고 있던 모든 속성들도 외래키를 추가한 다측 개체 릴레이션의 속성으로 함께 변환.

 

일대일 변환의 경우

기본적으론 변환 규칙은 다음과 같습니다.

관계 자체를 하나의 외래키 속성으로 변환.

한쪽 개체 릴레이션의 기본키 속성을 가져와 다른쪽 개체 릴레이션에 외래키 속성으로 포함. 어느쪽을 하더라도 상관없음.

관계가 갖고 있던 모든 속성들도 외래키를 추가한 릴레이션의 속성으로 함께 변환.

 

추가로 이 경우엔 링크의 유형이 전체참여인지 부분참여인지에 따라 다릅니다.

한쪽만 전체 참여하는 경우, 이 경우엔 전체참여하는 개체 릴레이션에 외래키를 추가하는 게 좋습니다.

양쪽 다 전체다 부분참여하거나 전체참여하는 경우엔 서로의 기본키를 주고 받아 외래키로 지정할 수 있습니다.

 

다대다 변환의 경우

변환 규칙은 다음과 같습니다.

관계는 하나의 릴레이션으로 변환.

관계의 속성은 릴레이션의 속성으로 변환.

양쪽 릴레이션의 기본키 속성을 외래키 속성으로 포함시키고, 기본키의 조합을 관계 릴레이션의 기본키로 설정.

 

- 속성 변환

속성의 변환 규칙은 일반적으로 다음과 같습니다.

개체의 일반 속성은 릴레이션의 일반 속성으로.

관계의 일반 속성은 관계가 외래키로 표현되는 개체 릴레이션 또는 관계 릴레이션의 속성으로 변환.

 

그리고 추가로 여러 경우가 존재합니다.

만약 다중 값 속성의 경우에는,

다중값 속성은 새로운 릴레이션으로 분리합니다.

새로운 릴레이션의 기본키 속성으론 전에 소속된 릴레이션의 기본키 속성을 외래키로 포함하여 일반 속성과 외래키의 조합으로 기본키를 설정합니다.

다중값 속성이 가지는 최대 속성 값의 개수만큼 이름만 다르게 하여 속성으로 추가합니다.

 

만약 복합 속성의 경우에는,

복합 속성은 복합 속성이 아니라, 복합 속성을 구성하는 가장 하위의 속성들만 릴레이션에 추가시킵니다.

 

만약 유도 속성의 경우에는,

유도 속성은 중복을 최소화하기 위해 속성으로 변환하지 않습니다.

 

물리적 설계

물리적 설계 단계에선, 논리적 설계 단계까지 생성했던 스키마를 DBMS 안에 실제 물리적인 저장 구조를 생성하는 SQL 명령문들로 명세합니다.

그렇기 때문에 물리적 설계는 특정 DBMS의 언어에 의존적입니다.

이 단계에서 하드웨어, 운영체제, 사용하는 DBMS에 따른 내부 저장구조, 접근 방식 등이 결정됩니다.

이 단계에선 프로그램 코드 안에서 직접 사용되기 때문에 열 이름이나 테이블 이름을 모두 영문으로 변환시켜줍니다.

필요하다면 뷰나 인덱스를 생성합니다.