데이터베이스 설계

데이터베이스 설계 단계

데이터베이스 설계(database design)란 사용자의 요구사항(requirements)으로부터 현실세계를 반영한 데이터베이스의 구조를 도출해 내는 과정을 말한다. 여러 필드로 구성된 테이블을 어떠한 물리적 형태의 데이터베이스로 저장할 것인가를 결정하는 것이다.

데이터베이스 설계 단계는 요구사항분석으로부터 시작하여 개념적 설계, 논리적 설계, 물리적 설계 단계로 진행된다.

[데이터베이스 설계 단계]

1. 요구사항 분석 : DB를 활용하게 되는 업무 내용, 운영 환경, 처리 조건등을 분석하여 DB가 제공해야 하는 핵심 정보 대상 및 제한 조건을 도출

2. 개념적 설계 

- 요구사항 분석에서 나온 분석 결과를 추상화된 표현 방식으로 기술하는 단계로 개념적 스키마를 생성한다. 

- 사용자 요구사항 분석 후 컴퓨터의 표현 방식보다는 사용자가 이해하기 쉬운 형태로 표현하고 추상적인 형태로 설계하는 단계이다.

- 개체관계 모델이 대표적인 모델이다.

- DB의 형태를 직접 표현하기보단 추상적인 설계도면을 그리는 단계라고 보면 된다.

- 개념적스키마를 개체관계다이어그램 또는 ER스키마라고 부른다.

3. 논리적 설계 

- 개념적 스키마로 부터 논리적 데이터베이스 구조에 맞는 스키마를 생성하는 단계로 논리적 스키마가 생성된다.

- 테이블 스키마 또는 데이터베이스 스키마라고 부르며 ERD를 이용하여 DB스키마를 설계 

4. 물리적 설계 

- 논리적 스키마로부터 효율적이고 구현 가능한 물리적 데이터베이스 구조를 설계하는 단계로 실제 컴퓨터에 저자오디는 방식설계

- 특정 DBMS가 제공하는 물리적 구조에 따라 테이블 저장 구조 설계하며 이러한 실제적인 저장구조를 물리적 스키마라고 한다.

- 테이블의 각 필드에 대한 데이터 타입만 결정하고 SQL create table문을 이용하여 테이블 생성

[데이터베이스 설계 단계]

---

설계 과정의 고려사항

앞서 설명한 대로 데이터베이스 설계의 최종 목표는 테이블의 물리적 구조를 결정하고 이를 DBMS에 구현하는 것이다. DB를 구축하여 실제로 운영하는 과정 중에서 발생되는 예상치 못한 문제점은 대부분 잘못된 설계에 기인한다.

따라서 이러한 문제점을 최소화하기 위해서는 설계과정에서 신중히 설계하는 것이 매우 중요하다.

1. 충실성

필요로 하는 모든 데이터를 표현하는 것이다.

구축된 DB는 사용자와 응용프로그램이 필요로 하는 모든 정보를 표현할 수 있어야한다. 요구사항에는 분명 기재되어 있는 사실이 실제 설계 과정에서 누락된다면 추후 DB를 구축하여 운용,관리 할 때 사실들을 저장하지 못하는 경우가 발생한다.

또한 요구사항에 존재하지 않는 사실이 설계과정에 나타나는 것도 문제이다. DB는 현실세계를 반영한 것이므로 DB에 저장된 모든 데이터는 실제 존재하는 사실로 인정되는 것이다. 따라서 이러한 문제는 무결성을 해치는 결과를 낳는다.

2. 단순성

단순하고 이해하기 쉬운 구조로 표현한다. 

테이블 스키마는 사용자의 요구 조건을 추상화하여 표현한 것이다. 따라서 요구사항이 무엇이었는지를 역으로 파악할 수 있도록 단순한 구조를 가져야한다.

3. 중복의 최소화

데이터의 중복을 최소화하며 저정공간의 낭비없이 효율적으로 사용하는것과 데이터의 일관성을 유지해야한다. 

4. 제약조건의 표현

사용자의 요구사항에는 데이터의 종류뿐만 아니라 데이터가 갖추어야할 특성(조건)도 동시에 표현한다.

---

개체집합과 속성

개채란 현실세계에서 물리적, 추상적으로 존재하는 실체를 말한다. 서로 독립적으로 존재하며 서로를 분별할 수 있는 특성을 가지고 있다.

동일한 특성을 갖는 개체들의 모임을 개체집합이라 하며 예로 홍길동, 황진이, 컴퓨터공학, 정보통신공학은 개개인이나 개별학과에 대한 개체이며 {홍길동, 황진이, ... }은 학생이라는 개체집합, {컴퓨터공학, 정보통신공학,...}은 학과라는 개체집합이라 표현할 수 있다.

속성이란 개체가 동일한 톡성을 가지고 있다는것을 판별하기 위한 것이며 개체의 특성을 말한다. 즉 개체집합은 동일한 속성을 갖는 개체들의 집합으로 표현할 수 있다. 관계형 데이터 모델의 필드와 같은 개념이지만 개체관계 모델의 속성은 원자값만을 허용하지는 않는다. 이를 다중값 속성과 복합속성으로 정의할 수 있으며 예를 들어 학생 개체집합에 family_member라는 속성이 정의 되어있다면 이 속성에는 하나 이상의 가족이름이 들어간다. 이와 같은 유형의 속성을 다중값 속성이라고 한다. 다른 예로 학생 개체집합에 address속성이 정의 되어 있고 이 속성은 더 작은 단위인 (district,city,street)으로 구성될 수 있다 이처럼 속성이 여러 개의 작은 단위로 나눠지는 경우를 복합 속성이라 한다.

-다중값 속성 : 하나의 속성에 여러 개의 값이 들어감

-복합 속성 : 하나의 속성이 여러개의 속성으로 구성됨

관계란 개체와 더불어 현실세계를 표현하는데 가장 중요한 추상적 개념이며 개체 간의 대응성을 의미한다. 개체간의 관계를 통해 의미를 규정할 수 있다. 예를 들어 개체 김광식은 개체 컴퓨터공학과에 소속된다.에서 소석이라는 관계를 갖게된다. 이와 같이 관계는 단독으로 정의하지 못하고 개체간의 연관성을 통해 자신의 의미를 나타내게 된다. 관계집합도 개체집합과 마찬가지로 속성을 정의할 수 있다.

---

관계의 대응수

관계집합에서 각 개체들이 참여할 수 있는 대응의 개수

-일 대 일(one-to-one)

개체집합 X의 각 개체는 개체집합 Y의 개체 하나와만 관련될 수 있고 Y의 각 개체도 X의 개체 하나와 관련될 수 있다. 

만약 교과목이라는 개체와 강의라는 개체와 개설이라는 관계에 있다면 한 교과목은 한학기에 한번만 강의를 개설 할 수 있고 강의도 한번에 한 교과목만 할 수 있으므로 둘의 대응수는 일대일이 된다.

-일 대 다(one-to-many)

개체집합 X의 각 개체는 개체집합 Y의 여러 개체와 관련될 수 있지만 개체집합 Y의 각 개체는 X의 개체 하나와 관련될 수 있다. 

예를 들어 한 학생은 하나의 학과만 포함되어있고 한 학과의 개체는 여러 학생을 받을 수 있다. 따라서 이들간의 대응수는 일대다가 된다.

-다 대 다(many-to-many)

개체집합 X의 각 개체는 개체집합 Y의 여러 개체와 관련될 수 있고 개체집합 Y의 각 개체는 X의 개체 여러 개체와 관련될 수 있다. 

예를들어 각 학생은 여러 강좌를 수강할 수 있고 각 강좌는 수강생이 여러명일 수 도 있다 따라서 이들간의 대응수는 다대다가 된다

---

약성 개체집합과 강성 개체집합

이제 개체집합을 속성의 완성도에 따라 구분해 보자. 어떤 개체집합은 기본키를 형성하는데 필요한 속성들을 모두 갖지 못한 경우가 있는데 이러한 개체 집합을 약성개체집합이라고 한다.

//기본키 형성에 필요한 속성을 모두 갖지 못한 개체집합 = 약성개체집합

반면 기본키를 가지고 있는 일반적인 개체집합을 강성 개체집합이라고 한다.

//기본키 형성에 필요한 속성으 모두 갖는 개체집합 = 강성개체집합

예를 들어)

course 개체집합에 속성은 {course_id , title, credit}일 때 기본키는 course_id이므로 강성개체집합

class 개체집합에 속성은 {year, semester, division, classroom, enroll}일때 {year, semester, division}은 동일 교과목(course) 내에서만 유일하고 그 이외의 속성 조합으로도 기본키가 될만한 것들이 없기 때문에 약성개체집합이며 약성개체집합의 존재가 강성개체집합의 존재에 의해 결정된다

//class 개체집합은 그 자체의 속성만으로는 기본키를 결정할 수 없어서 약성개체집합이 된다.

[강성개체집합과 약성개체집합의 그림]

대응관계 차원에서 약성 개체집합과 강성 개체집합은 항상 다대일 관계를 맺게되며 약성 개체집합의 모든 개체가 다대일 관계에 빠짐없이 참여하는데 이를 전체참여라고 부른다.  // class개체집합에서 하나의 분반에는 하나의 강의만이 연결되어있다.(같은 공간에서 서로 다른 수업을 할 수 없으므로)

위 그림을 볼때 class 개체집합의 모든 개체들은 course 개체집합의 개체와 관계를 맺는다면 전체참여이다. 

만약 class개체집합의 개체 중에서 course 개체집합의 개체와 관계를 맺지 않는것이 존재한다면 class개체집합은 course개체 집합과의 관계에서 부분참여라고 부른다 

앞서 기본키의 유무에 따라 판단한다고 정의했는데 이 정의만으로 강성개체집합과 약성개체집합을 구분하기는 쉽지않다. 약성개체집합을 판별하는 손쉬운 방법은 이 개체집합이 의존하는 강성 개체집합이 존재하는 가를 보는 것이다. 

예를 들어 직원개체집합과 부양가족 개체집합과의 관계, 건물개체집합과 내부사무실 개체집합과의 관계를 보면 우선 부양가족 개체집합의 모든 개체는 직원 개체집합의 개체와 관계를 맺을 것이며 부양가족 개체의 존재는 직원개체 집합의 존재에 의지한다. 부양가족 개체집합이 단독으로 존재할 수 없는것이다. 또한 건물과 내부사무실 개체집합간의 관계도 마찬가지로 건물 개체집합이 존재하지 않는다면 내부사무실 개체 역시 존재할 수 없다.

이와 같이 약성개체집합은 그와 관련된 강성 개체집합과 관계를 형성하는 것이 일반적이며 이때 약성 개체집합은 강성 개체집합에 종속관계에 있다고 말한다. 이는 약성 개체집합은 강성 개체집합과의 관계를 통해서만 존재할 수 있음을 의마한다.

약성 개체집합에서 강성 개체집합의 특정 개체 내에서 유일한 값을 갖는 속성 집합을 부분키 또는 구별자라고 부른다. 예를 들어 class개체 집합 {year, semester, division}은 특정 교과목 내에서는 유일하므로 {year, semester, division}는 부분키이다.

약성개체집합은 그 자체로는 기본키를 갖지 못한다고 하였다. 따라서 종속관계에 있는 강성 개체집합의 도움을 받아야한다. 즉 양성개체집합의 기본키는 자신의 부분키와 강성개체집합의 기본키로 구성된다 따라서 class개체집합의 기본키는 {course_id, year, semester, division}로 정의할 수 있다.