Chapter1 - 데이터베이스 설계

데이터베이스 설계

데이터베이스 시스템은 많은 양의 정보를 관리하기 위해 설계된다. 이 많은 양의 정보는 별개의 정보들로 존재하지 않는다. 이 정보들은 회사 운영에 필요한 데이터베이스 혹은 어떤 장치 혹은 서비스에 관련된 자료들이라 할 수 있다.

    데이터베이스 설계는 데이터베이스 스키마 설계와 주로 관련된다. 모델화된 회사의 요구를 만족시켜주기 위한 완벽한 데이터베이스 응용 프로그램의 설계는 많은 문제점들을 주의해야 한다.

• 설계 단계
  

상위 데이터 모델은 데이터베이스 설계자에게 데이터베이스 사용자의 데이터 요구조건들을 기술하기 위한 개념적인 골격과 데이터베이스가 이러한

요구조건을 만족시키기 위해 어떻게 구성될 것인가에 대한 것을 제공한다. 데이터베이스 설계의 초기 단계는 장래의 데이터베이스 이용자들이 필요로 하는 데이터를 충분히 규정하는 것이다. 이런 일들을 수행하기 위해 데이터베이스설계자는 그 분야의 전문가들 및 사용자들과 광범위하게 상호 작용해야 한다. 이 단계의 결과물은 사용자의 요구 명세서(specification of user requirements)이다.

    다음으로 설계자는 데이터 모델을 선택하고, 선택한 데이터 모델의 개념을 적용함으로써 이러한 요구들을 데이터베이스의 개념적인 스키마로 바꾼다. 이러한 개념적 설계의 단계에서 개발된 스키마는 기업의 상세한 개관(overview)을 제공한다. 설계자는 모든 요구들이 실제로 만족되었는지, 그리고 그러한 요구들이 서로 충돌하는 것은 아닌지 확실히 하기 위해 스키마를 재검토 한다. 또한 중복되는 사항들(redundant features)을 제거하기 위해 살펴볼 수 있다. 이때 설계자의 초점은 물리적으로 어떻게 저장할 것인지 자세히 규정하는 것 보다는 데이터와 그들의 관계를 기술하는 데 맞추어져 있다.

    관계형 모델에서의 개념적 설계 단계는 데이터베이스에서 우리가 포착하길 원하는 어떤(what) 속성과 다양한 테이블을 구성하는 이러한 속성을 어떻게(how) 그룹화할 것인가에 대한 결정과 관련되어 진다. "어떠한 것(what)"은 기본적으로 기업적인 결정으로 여기서 다루지는 않는다. "어떻게(how)"는 주로 전산학의 문제이다. 이러한 문제를 다루는 두 가지 방법이 있다. 하나는 개체-관계 모델을 사용하는 것이다. 나머지 하나는 모든 속성들의 집합을 입력으로 받아 테이블의 집합을 생성하는 알고리즘(정규화로 알려져있다)을 사용하는 것이다.

    또 완전히 개발된 개념적 스키마는 실게계의 기능적인 요구사항들을 보여준다. 기능적 요구사항 명세서(specification of functional requirement)에 사용자들은 데이터에 적용될 연산(혹은 트랜잭션)들의 종류를 기술한다. 이런 연산들의 예를 들면 데이터의 변경 혹은 갱신, 특정 데이터의 검색 및 추출, 데이터의 삭제들이 있다. 개념적 설계의 이 단계에서 설계자는 스키마가 기능적인 요구사항들을 만족시키는지 확인하기 위해 재검토할 수 있다.

    추상 데이터 모델로부터 데이터베이스 구현으로 이동하는 과정은 마지막 두 가지 디자인 단계에서 이루어진다. 논리 설계 단계(logical-design phase)에서 설계자는 상위의 개념적 스키마를 사용할 데이터베이스의 구현 데이터 모델에 대응시킨다. 설계자는 결과로 나온 시스템 특유의 데이터베이스 스키마를 데이터베이스의 물리적 속성들이 구체화 되는 다음 단계인 물리 설계 단계(physical-design phase)에 이용한다. 이러한 속성들은 파일 구성(file organization)의 형식과 내부적인 저장 구조들을 포함한다.

• 개체-관계 모델(Entity-Relationship)
  

개체-관계 데이터 모델(E-R 모델)은 기본적인 객체를 나타내는 개체(entity)들과 개체들 간의 관계(relationship)를 이용한다. 개체는 실세계에 존재하는 '어떤 것' 혹은 '객체'이며 다른 객체들과 구별된다. 예를 들어 각 사람은 개체이고, 은행 계좌도 개채라고 할 수 있다.

    개체는 데이터베이스에서 속성(attribute)의 집합으로 기술된다. 예를 들어, dept_name, building, budget 속성은 대학교의 특정 학과에 대한 정보를 기술하며, 그들은 department 개체집합의 속성의 형태를 띤다. 유사한 방식으로 ID, name, salary 속성은 instructor(교수) 개체를 기술한다.

    이들외에 ID라는 속성을 따로 두어, 교수를 유일하게 구분하는 데 사용한다(같은 이름과 같은 급여를 가진 두 명의 교수가 있을 수 있기 때문이다). 각각의 교수를 유일하게 구별하기 위해 고유의 식별자를 부여한다. 미국에서는 많은 기업들이 개인의 사회 보장 번호(미국 정부가 각 국민들에게 할당한 고유 번호)를 고유한 식별자로 사용한다.

    관계(relationship)란 여러 개체들 간의 연관성을 말한다. 예를 들어, member 관계는 교수와 학과를 연관시킨다. 같은 형의 개체들의 집합과 같은 형의 모든 관계들의 집합을 각각 개체 집합(entity set) 과 관계 집합(relationship set)이라 부른다.

    데이터베이스의 전체 논리적 구조(스키마)는 개체-관계 다이어그램(E-R diagram)으로써 시각적으로 도식할 수 있다. 이러한 다이어그램은 여러 가지 방법으로 나타낼 수 있다. 가장 많이 쓰이는 방법은 통일된 모델링 언어(UML)를 이용하는 것이다. UML을 기반으로 한 E-R 다이어그램은 다음과 같이 나타낸다.

• 개체 집합은 윗부분에 개체 집합의 이름을 갖고 그 아래에 속성들의 목록을 갖는 사각형박스로 표현된다.
• 관계 집합은 연관된 개체 집합들의 쌍을 연결한 마름모로 표현된다. 관계의 이름은 마름모 안에 위치한다.

한 예로, 교수들과 그들이 속한 학과들로 구성된 대학교 데이터베이스의 일부를 고려해보자. 아래의 그림은 이에 대응하는 E-R 다이어그램을 나타낸다. 앞서 기술한 속성들을 가진 두 개의 개체 집합 instructor 와 department 그리고 이들 사이의 관계를 나타내는 member 관계도 볼 수 있다.

    개체와 관계를 비롯하여, E-R 모델은 데이터베이스가 의미적으로 반드시 만족해야만 하는 제약조건들을 표현한다. 중요한 제약조건 중 하나가 바로 대응 수(mapping cardinality) 이다. 이것은 어떤개ㅔ가 하나의 관계 집합을 매개로 관련될 수 있는 개체의 수를 가리킨다. 예를 들어, 교수가 하나의 학과에만 속애햐 한다면, E-R 모델은 이를 적절하게 나타낼 수 있어야 한다. 개체-관계 모델은 데이터베이스를 설계하는데 널리 쓰이고 있다.

• 정규화

관계형 데이터베이스를 설계하는 또 다른 방법은 일반적으로 정규화로 알려진 단계를 이용하는 것이다. 정규화 목표는 불필요하게 중복 저장되는 정보가 없고, 정보 검색을 쉽게 할 수 있는 릴레이션(Relation) 스키마 집합을 생성하는 것이다. 정규화의 방법은 적당한 정규형(normal form) 에 맞게 스키마를 설계하는 것이다. 어떤 릴레이션 스키마가 올바른 정규형들에 속하는지를 결정하기 위해서는 데이터베이스로 표현하려고 하는 실세계 응용에 대한 부가적인 정보가 더 필요하다. 가장 많이 사용되는 방법은 함수 종속(functional dependency)을 사용하는 것이다. 

    정규화의 필요성을 이해하기 위해 잘못된 데이터베이스 설계로 인해 어떤 문제들이 생길 수 있는지 살펴보도록 하자. 잘못된 설계로 인해 생기는 문제점들에는 다음과 같은 것들이 있을 수 있다.

• 정보의 중복

• 특정 정보의 표현이 불가능

이전에 대하교 예제에 사용한 데이터베이스 설계를 수정하면서 이러한 문제들을 살펴보자.

instructor 와 department 라는 두 별도의 테이블을 갖는 대신에, 두 테이블의 정보를 합쳐놓은 faculty 라는 하나의 테이블을 갖는다고 하자. faculty  테이블에는 역사학과가 위치한 건물과 그 학과의 예산에 대한 정보가 반복되어 있다. 이와 같은 새로운 설계에서의 정보의 반복은 바람직하지 않다. 반복된 정보는 공간을 낭비한다. 게다가 데이터베이스의 갤신을 어렵게 한다. 역사학과의 예산을 50,000 달러에서 46,800 달러로 변경한다고 가정하자. 이러한 변경은 두 개의 행에 반영되어야 한다. 이는 하나의 행만을 갱신하는 원래의 설계와는 대조적이다. 따라서 새로운 설계에서의 갱신은 원래의 걸계보다 많은 비용이 든다. 새로운 데이터베이스에서 갱신을 하려면, 역사학과를 가지는 모든 투플이 갱신되어야 하며, 그렇지 않은 경우에는 서로 다른 역사학과의 예산에 대해 서로 다른 값을 가지게 된다.

ID	name	salary	dept_name	building	budget
22222	Wu	90000	Finance	Painter	120000
12123	El Said	60000	History	Painter	50000
45565	Katz	75000	Comp.Sci	Taylor	100000
..	..	..	..	..	..
..	..	..	..	..	..
10101	Brandt	65000	Comp.Sci	Taylor	100000
..	..	..	..	..	..
33546	singh	92000	Comp.Sci	Taylor	100000

faculty 테이블 

   ->instructor 와 department 로 분화시 조회 성능 , 삽입 성능 

빨간 글씨 : 중복 - 변경시 속도  , 조회 성능 , 삽입 성능 

"특정 정보의 표현이 불가능"의 문제점에 대해서 알아보자. 대학교에 새로운 학과를 만든다고 가정하자. 위의 새로운 설계에서는 학과가 최소 한 명의 교수를 갖지 않으면 학과의 정보 (dept_name, building, budget) 를 직접적으로 나타낼 수가 없다. 이것은 faculty 테이블의 행들이 ID, name, salart 정보를 필요로 하기 때문이다. 이것은 새로 생성된 학과에 첫 교수가 고용되기 전 까지는 해당 학과의 정보를 저장할 수 없다는 것을 의미한다.

    이 문제를 해결하기 위한 한 가지 방법은 널(NULL)값을 도입하는 것이다. 널 값은 값이 존재하지 않는 (혹은 알려지지 않은) 값을 나타낸다. 알려지지 않은 값은 missing(값이 존재한다. 하지만 정보를 가지고 있지 않다) 이거나 not known(값이 실제로 존재하는지 존재하지 않는지를 알지 못한다)이다. 이후에 알겠지만 널 값은 다루기가 힘들어 널 값에 의지하지 않는 것이 바람직하다. 널 값을 다루지 않는다면 학과에 최소 한 명의 교수가 있을 때에만 학과 정보의 특정한 항목을 생성할 수 있다. 게다가 마지막 교수가 있을 때에만 학과 정보의 특정한 항목을 생성할 수 있다. 게다가 마지막 교수가 학과에서 떠나면 이 정보는 삭제되어야 한다. 원래의 설계 에서는 학과 정보가 교수의 존재 여부와 관계 없이, 또 널 값에 의존하지 않아도 이용 가능하였기 때문에 분명하게 이 상황은 바람직하지 않다.

    정규화의 광범위한 이론은 어떤 데이터베이스 설계가 바람직하지 않고, 어떻게 바람직한 설계를 해야 하는지에 대한 형식적인 정의를 돕기 위해 개발 되었다.