알기쉽게 해설한 데이터 베이스론 2장 1)

개체집합(ENTITY SET)

객체(ENTITY)또는 객체(OBJECT)

  개체란, 실제 세상에 있는 객체(OBJECT)이다. 개체와 객체는 뜻이 거의 같아서 서로 바꾸어 쓸 수 있다고 보면 된다.

  객체는 다른 객체와 구별되는데, 객체의 보기로는 각 사람, 각 자동차, 각 과목등이 있다. 각 사람은 다른 사람과 구별되며, 각 자동차도 서로 구별된다. 마찬가지로 각 과목도 서로 구별된다. 그런데, 사람이나 자동차는 실제로 만질수 있지만, 과목등은 그럴수 없다 그런데 개체-관계 모델에서는 구별하지 않는다

  개체집합(ENTITY SET)

  개체집합이란 같은 형의 개체의 집합이다. 보기를 들어 학생 개체집합, 은행의 고객 개체 집합, 교수의 개체의 집합 등이다. 그런데 개체집합은 반드시 서로 겹치지 안하야 하는 것이 아니라 겹칠수도 있다.

  즉 은행과 회사에 모두 김말동이라는 데이터베이스를 사용한다면 김말동은 은행과 회사 양쪽 개체집합에 모두 속한다.

 속성(attribute 또는 property)

  개체는 속성(attribute 또는 property)의 집합으로 나타낸다. 보기를 들어, 유저개체는, 비밀번호, 아이디, 캐릭터등의 속성으로 나타낸다.

  도메인(= 범위, domain)

  속성과 관련하여 도메인(=범위)라는 용어를 자주 쓰는데, 도메인이란, 어떤 속성의 값으로 될 수 있는 모든 값의 집합을 가리킨다. 보기를 들어, 유저의 이름이 맨 앞에 앞의 한자리를 성으로를 포함하여 일곱자리라고 하면, 이때 학번의 도메인(=범위)는 일곱자리이다.

  이런 이름의 속성은 문자열이고, 과목 이름은 일곱자리 문자열 이다.

  특히 SQL에서는 프로그램할 때는 자료의 형과 도메인을 거의 같이 다루기 때문에 이런 혼란이 생기게 된다.

  어떤 속성의 자료형과 도메인을 엄격하게 구별하지 않더라도, 실제로는 크게 혼란이 없는데, 엄밀하게 말하면, 도메인은 속성에 허용되는 값의 집합이지만, 경우에 따라서는 속성에 대한 자료형(보기 int, char(20))을 도메인이라고 보아도 될 것이다. 자료형으로 속성의 도메인을 나타냈더라도, 필요하다면 언제든지 실제로 허용되는 값인지 아닌지 엄격하게 확인하여, 잘못된 값이면(다시 말하여 도메인 밖의 값이라면)받아들이지 않으면 될 것이다.

  (도메인의 조건에 이름의 길이 말고도 다른 제한이 가능한지는 한번 물어보자.)

  

  속성의 형

  이제 속성의 형에(attribute type)에 대하여 살펴보자, 속성의 형은 두가지 다른 기준으로 독립적으로 나눌 수 있는데, 구체적으로 보면

  단순(simple) 속성과 복합(composite)속성

  값이 하나인(single-valued)속성과 값이 여럿인(multi-valued)속성

  이 두가지는 독립적이기 때문에 조합하면 다음과 같이 네가지 속성의 형이 나오게 된다.

  단순하면서 값이 하나

  단순하면서 값이 여럿

  복합이면서 값이 하나

  복합이면서 값이 여럿

  단순속성

  

  우리가 보통 쓰는 속성은 단순속성이다.

  create table 유저 {순서인덱스 char(7), 이름 char(20), 캐릭터 char(15)}

  

  복합 속성

  날짜를 여덟글자로 나타내는데, 연, 월, 일로 나눈다고 하면 다음과 같이 글자는 8글자로 나누고 연도는 4자리, 월 2자리 등으로 표현하면 이는 복합속성이다.

  하지만 이는 만약 가상적으로(SQL에서는 못하지만) 설정한 것이다.

  create table 날짜 { 날짜 (char(4), 월 char(2), 일 char(2)) }

  복합 속성은, 관계형 데이터베이스에서는 사용할 수 없다.

  값이 하나인(single - valued) 여럿인(multi-valued) 속성

  이제 값이 하나인 속성과 값이 여럿인 속성에 대하여 살펴보자, 보기를 들어, 학생이 세 과목을 수강한다는 사실을 다음과 같이 나타내면, 과목번호 속성은 값이 하나인 속성이다.

create table 수강1 (학번 char(7) , 과목번호 char(5)) ;

수강1 학번 과목번호 

99021 01 , CS333 

99021 01 , CS444 

9902101 , CS555

  그러나 학생이 세과목을 수강한다는 사실을 "가상적으로"(SQL에서는 역시 다음과 같이 못한다) 표시한다면 이는 값이 여럿인 속성이다.

create table 수강2 (학번 char(7) , 과목번호-목록 5et of char(5)) ;

수강2 학번 char(7) , 과목번호-목록 

9902101 , {CS333, CS444, CS555}

널(null) 값

  영어로는 null이라고 하는데, 이 말은 라틴 말 nullus에서 온 말이다. nullus는 n(아님) ullus(어떤 것도)가 더해진 것이다. 원래 뜻은 "값이 없다" 비었다, 0이다 등의 뜻이다.

 sql에서는 여러가지 의미로 쓰이므  null값은 다루기 골치 아프다. 

 

 1. 해당되지 않음

 2. 빠진 값

 3. 잘 모름

 null값은 될수록 쓰지 않는 것이 좋다고 본다. 특힝 예상되는 이상한 값은 null값 대신, 설계할 때 미리 정해둔 값을 쓰는 것이 좋다.

 관계 집합(relationship set)

  관계란 개체 두개 또는 여러 개 사이의 연관을 말한다. 관계 집합이란 같은 형의 관계를 모은 것을 말한다.

  예를 들어 학생과 과목이라는 객체가 있을때 어느 학생이 어느 과목을 듣는지(=연관)을 생각해 볼수 있는데.

  이것을 수강 관계라고 할수 있다.

  위에서 객체의 속성을 배웠는데, 관계에도 속성이 있을 수 있다. 

  보기를 들어 학생과 과목 객체 사이의 수강 관계에서 학생이 받은 성적 등급 속성을 생각 할 수 있다. 만일 성적 등급이 어떤 과목 객체의 속성이라면, 

  그 과목을 듣는 모든 학생이 꼭 같은 성적을 받는 웃지 못할 일이 생긴다.

  그러므로 성적은 학생과 과목 객체 사이의 수강 관계의 속성으로 나타내는 것이 옳다.

  거의 모든 관계가 두 객체 사이의 관계인 이진(binary)관계 이지만, 가끔 세개 이상의 객체 관계도 있을수 있다.

  객체 집합으로 나타낼까, 관계 집합으로 나타낼까.

  위에서 객체 집합과 관계 집합을 살펴보았는데 설계를 하다보면 실제로 어떤 것을 객체로 나타낼지, 아니면 관계로 나타낼지 뚜렷하지 않을 때가 있는데 그건 너무나 당연하므로 걱정하지 않아도 된다. 그런 경우, 반드시 객체로 해야 한다든지, 아니면 반드시 관계로 해야한다든지 하는 규칙은 전혀 없다.

  사상(=매핑)제약 조건(mapping constraints)

   두 객체 사이에 이진 관계가 있을때, 저 쪽 객체에 연결될 수 있는 이쪽 객체의 수를 사상 크기(mapping cardinalities)라고 한다. 이 관계는 1:1 1:n m:1 m:n 네가지가 있다. 전화번호와 그 전화번호 소유자 사이의 관계를 보기로 매핑크기를 살펴보자.

  1. 전화번호 : 소유자_주번 = n:1

  전화번호는 소유자가 한명 뿐이다.

  그러나 한 사람이 여러대의 전화를 가질 수 있다.

  2. 전화번호 : 소유자_주번 = 1:n

  각 사람은 전화번호를 하나만 가질수 있다.

  그러나 여러 사람이 한대의 전화를 같이 가질 수 있다.

  3. 전화번호 : 소유자_주번 = 1:1

  각 전화번호는 소유자가 한명이고

  각 사람은 전화번호를 하나만 가질 수 있다.

  달리 말하면 각 사람은 전화번호 하나만, 각자 독점적으로 가지게 된다

  4. 전화번호 : 소유자_주번 = m:n

  한사람은 여러개의 전화번호를 가질 수 있고,

  한 전화번호는 여러 사람이 같이 쓸 수 있다.

  이런 네가지 가능성 가운데 우리 현실에 가장 가까운 것을 찾는다면 일반적으로 4번일 것이다.

  이는 대학으로 치면 학생이 학과를 이중 전공하고 학과는 여러학생이 모여잇다고 친다면 있을 때도 4번과 같이 나눌 수 있다.

  키(key)

  객체 집합이 있을 때 그 안에 있는 각 객체를 어떻게 구별할 수 있을까 하는 문제가 있다. 물론 관계 집합에서도 마찬가지로 관계 집합 안에 관계가 여러개 있을때 그안에 있는 각 관계를 어떻게 구별할까 인데 개체-관계 모델에서는 결국 그 객체의 속성 값으로 구별할 수 밖에 없다.

  이제 개체 집합에서 특정 개체를 가리킬 수 있는 여러가지 키에 대하여 배워보자. 

  수퍼키(SK: superkey)

  개체집합에서는 어떤 개체를 유일하게 가리킬 수 있는 하나 이상(= 하나 또는 여러)속성의 집합을 "수퍼키"라고 한다. 후보기에 필요한 속성말고 더 많은(super)속성이 있을 수 있어서 superkey라고 하는데, 이때 super는 우리말로 넘치는 뜻이 있다.

  ex)

  학번은 각 학생을 유일하게 가리킬수 있으므로, 학번은 수퍼키이다. 위에서 보았듯이 키는 속성의 집합이므로, 학번자체가 키가 아니라 {학번}이 키이다.

  {학번, 이름}은 각 학생을 유일하게 가리킬 수 있으므로 {학번, 이름}은 수퍼키이다.

  {주번}은 수퍼키일까? 주번은 사람을 유일하게 가리킬수 잇으므로 수퍼키이다.

  {이름}은 수퍼키일까? 이름이 같은 사람은 있을수 잇으므로 이름은 수퍼키가 아니다.

  후보키(CK, candidate key)

  주어진 수퍼키의 속성에서, 어떤 속성을 뺀 뒤에도 수퍼키가 될수 있다면, 주어진 수퍼키는 후보키가 아니다. 달리 말하면, 주어진 수퍼키의 속성에서 속성 하나라도 뺀다면 수퍼키가 될 수 없을 때, 주어진 수퍼키를 후보 키라고 부른다.

  다른 각도에서 보면, 후보키는 최소의 수퍼키이다. 말로하자니 후보키가 좀 어렵지만 보기를 보면 쉽게 알수 있다.

 {학번, 이름}도 수퍼키이고, {학번} 도 수퍼키이다. 이중에서 이름을 빼도 {학번은 }수퍼키므로 후보키가 아니다.

  거기에 비해서 {학번}에서 속성을 하나라도 빼면 {}이 되어 버리므로(빈 집합 : empty set)가 되어버리므로 더 이상 수퍼키가 아니다. 따라서 {학번}은 후보 키이다.

  {주민번호}는 후보키 일까? 만일 주민 등록 번호가 겹치지 않는다고 가정하면, 위에서 보았듯이 주번은 수퍼키이고, 속성 하나로 이루어진 수퍼키는 후보키 이므로 {주번}은 후보키이다.

  일차 키(PK: primary key)

  주어진 객체 집합 또는 관계 집합에 만일 후보키가 하나뿐이면, 그것이 저절로 일차키가 된다. 그런데, 만일 주어진 집합에 후보키가 둘이상 잇으면, 데이터베이스를 설계할 때 그 가운데 하나를 일차키로 고르고 나머지는 그냥 후보키가 된다.

  그러면 일차 키인{학번}과 일차 키가 되지 못한 후보 키{주번}은 어떻게 다를까? 나중에 참조 무결성을 볼때 알겠지만, 보기를 들어, 학생 객체집합과 과목 객체 집합 사이의 수강관계 집합에서, 학생 객체를 가리킬 때 일차키인 {학번}을 쓰며, 일차키가 아닌 후보키 {주번}을 쓰지 않게 된다. 이것이 일차키가 아닌 후보키 사이의 아주 중요한 차이이다.

학생 객체 집합={ (9902101 , 흥길동, 790101-1234567 , ... ), 

(9902102, 박두리, 791212-3456789, .. .), .. .} 

과목 객체 집합={ (CS100, 컴퓨터 개론 .. . ), 

(CS200, 프로그래밍, .. . ), 

(CS300, 데이터베이스 , ... ) } 

수강 관계 집합1={ (9902101 , CS100, ... ), 

(9902101 , CS200, .. .) , 

(9902102, CS200, ... ), 

(9902102, CS300, .. . )}

  위의 수강 관계 집합1에서 보듯이, 학생 객체를 가리킬 때 일차 키인 {학번} 9902101, 9902102 등으로 나타낸다. 다시말해서 수강관계 집합2에서와 같이 {주번}으로 가리키지 않는다는 것이다. 일차 키와 일차 키가 아닌 후보 키는 이 보기를 통하여 확실히 이해하였으리라 본다.

  수강 관계 집합2={ (790101-1234567 , CS100 , ... ), 

(790101 -1234567, CS200, ... ), 

(791212-3456789, CS200 , ... ), 

(791212-3456789, CS300, ... )}

  

    그런데, 위에서 수퍼키, 후보 키, 일차 키 등을 배웠는데, 어떤 속성이 그냥 키이다. 아니다라고 말할 수는 없고, 주어진 집합안에서 키이다 아니다라고 말할 수 있다. 구체적인 보기를 들자면, 학생 집합에서 학번은 후보 키이지만, 그렇다고 {학번}이 늘 후보키라고 할 수는 없다는 것이다.

  보기를 들어 수강 관계 집합을 생각해 보자. 학번이 9902101 인 학생이 세 과목 을 수강하면, 수강 관계 집합에는 그 학번이 있는 객체가 세 개 있다. 실제로 수강 관계 집합의 후보 키는 {학번 , 과목번호}이다. 따라서 {학번}이 학생 객체 집합에 서는 후보 키이지만, 수강 관계 집합에서는 후보 키가 아니다. 

  따라서 {학번}이 일반적으로 키이다 또는 아니다라고 말할 수 없고, 어떤 객체 집합이 주어졌을 때 그 집합에서 {학번}이 키이다 또는 아니다라고 말할 수 있는 

것이다. 이 점은 아주 중요하므로 잘 알아두기 바란다. 즉 객체집합안에 들어가서야 키로서 의미를 지니게 된다.

  sort key

  수퍼키, 후보 키, 일차 키 등에서 말하는 키는 주어진 객체 집합 에서 그 키 값만 일면, 어떤 특정 객체를 가리킬 수 있다‘ 하지만, 간추리기를 할 때 쓰는 키 (sort key 또는 sort field) 라는 용어는, 위에서 배운 수퍼(=넘치는)/후보/일차 키에 나오는 키와 개념이 다르다 간추리기 키는 그냥 그 값으로 간추린다는 뜻이며, 그 따일 안에 간추리기 키 값이 같은 줄이 여러 개 있을 수도 있다. 보기를 들어, 수강 관계가 있는 파일을, 학번을 간추리 기 키로 하여 간추렬 수 있는데, 이 경우 학번이 같은 줄이 여러 개 나올 수 있다.

  즉 현재 테이블 안에서 sort key를 지정하고 이 키를 이용해서 테이블을 간추린다. 할때 그 키를 기준으로 정렬되는데 이럴때 사용하는 것이 sort key다.

  외래 키(foreign key)

  앞서 나온 키들은 주어진 테이블에서 특정 투플을 가리킬 수 있는 키이다. 여기서 투플이란 다음 설명을 보자.

		Attribute
Tuple

   릴레이션 (relation) 

같은 성격의 데이터들의 집합을 의미. 흔히 테이블이라고 말하는 용어와 같은 의미로 이론적인 용어. 

릴레이션은 튜플과 에트리뷰트로 데이터를 정렬하여 관리한다. 

   튜플 (tuple)

릴레이션의 각 행을 의미. 흔히 일반적인 용어로 레코드(record)와 로우(row)와 같은 의미로 사용된다. 

   에트리뷰트(attribute)

릴레이션에서 이름을 가진 하나의 열을 말한다. 흔히 일반적인 용어로 칼럼(column)과 같은 의미로 사용된다. 

   디그리(degree)

에트리뷰트의 수를 말한다. 

   카디널러티(cardinality)

튜플들의 수를 말한다. 

- 한 릴레이션에 정의된 튜플들은 모두 다르다. 

- 한 릴레이션에 정의된 튜플들은 순서에 무관하다. 

- 튜플들은 시간에 따라 변한다. 

- 릴레이션 스키마를 구성하는 에트리뷰트의 값은 동일해도 된다. 

- 에트리뷰트는 더 이상 쪼갤 수 없는 원자값으로 구성된다. 

- 릴레이션을 구성하는 튜플을 유일하게 식별하기 위한 속성들의 부분집합을 키(Key)로 설정한다. 

  

  외래키란 다른 테이블에서 일차키인 속성의 집합이 주어진 테이블이 있을때, 이 속성의 집합을 주어진 테이블에서 외래키라고 한다. 말로는 어려운듯 하지만 보기를 보면 쉽게 알수 있다.  일단 키를 구성하는 SQL 명령어를 보자

create table 수강 (학번 char(7) 과목번호 char (7), 

primary key (학번, 과목번호)) ; 

그리고 위에서 보았던 학생 테이블의 스키마는 다음과 같이 정의할 수 있었다. 

create table 학생 (학번 char(7) , 이 름 char (2이 , 

primary key (학번));

  위의 수강 테이블에서 {학번}은 일차 키가 아니지만 (일차 키는 {학번, 과목번호}), {학번}은 학생 테이블에서 일차 키이다. 따라서, 수강 테이블에서 {학번}은 외래 키이며, 이 사실까지 더하여 수강의 스키마를 SQL로 나타내면 다음과 같다.

create table 수강 (학번 char (7), 과목번호 char (7) , 

primary key (학번, 과목번호) , 

foreign key (학번) references 학생) ;

  수강 테이블의 일차 키는 {학번, 과목번호}인데 이 사실은 primary key 키 설정에 나타나있다. 수강 테이블의 {학번}은 외래키이고, {학번}은 학생 테이블에서 일차 키인데, 이 사실은 "foreign key (학번) references 학생"에 나타나있다. references 다음에는 학번이 일차 키인 테이블의 이름 학생이 온다.

  일반적으로 키라고 말할 때는, 어떤 테이블의 스키마에서 어떤 속성의 집합이 무슨 키라고 해야한다. 외래 키의 경우에도 이 말은 적용된다. 그냥 막연히 학번이 외래키라고 하는 건 틀리며 수강스키마에서 학번이 외래키라고 말해야 정확하다. 학생 스키마에서 학번은 일차키이므로 각 키가 소속된 테이블을 명확하게 명시해 주지 않고 말하면 틀린것이다.

  개체 관계도 (entity - relationship diagram)

  객체 관계 모델에서는 데이터베이스의 논리적인 구조를 그림으로 나타낼수 있는데. 이를 개체 관계도라고 한다. 프로그램의 순서도와도 마찬가지인데. 개체-관계도는 데이터베이스를 설계할 때의 순서도라고 생각하면 된다.

  이런 식으로 표현되는 것이 개체관계도를 의미한다.

  관계의 표현(relationship)의 표현

  관계란 여러 개체 사이에 존재하는 연관성을 말하는데, 보기를 들어 학생과 과목 사이에 수강이라는 관계가 있다면, 학생과 과목 객체를 수강이라는 관계로 연결하여 그려볼 수 있다.

  여기에 관계 속성인 수강 관계에 학점이라는 속성이 생긴다면 다음과 같이 표현할 수 있다. 학점은 학생이나 과목 어디에도 포함되지 않고 수강에 포함되는 속성이이다.

 이거 왠지 UML이랑 비슷해 지는 느낌인데. 사상크기또한 개체와 개체를 연결하는 선에 화살표를 사용하여 나타낸다. 사상크기는 아까 봤던대로, 1:1, 1:N, N:1, M:N이 있는데 이 내가지를 화살표로 다음과 같이 표현이 가능하다.

  이 관계도를 보고 테이블을 만드는 과정은 당연히 그 반대로 실행하면 된다. 또한 일차키에는 밑줄을 치는 방식으로 표현할 수가 있다.

  이렇게 구조도를 짜고 DB구조를 설계할때 주의해야할 점은

  관계를 테이블로 만드는 것은 개체를 테이블로 만드는 것보다 조금더 복잡한데. 위 그림에서 수강테이블을 말하는 것인데. 관계를 맺고 있는 개체의 사상 크기에 따라 만드는 방법이 다르다. 각 사상크기에 따른 테이블 생성 방법은 다음과 같다.

  1:1 관계 : 관계에 참여하는 한쪽 개체의 속성에 다른 쪽의 개체의 일차키를 포함시킨다. 관계 자체에 속성이 있는 경우, 한쪽 개체의 속성에 관계 자체의 속성도 포합시킨다.

  1:N N:1의 관계 : N쪽 개체에 대응하는 테이블의 속성에 1쪽 개체의 일차키를 포함시킨다.(외래 키가 됨). 관계 자체에 속성이 있을 경우, N 쪽 개체에 대응하는 테으블의 속성으로 관계 자체의 속성을 포함시킨다.

  M:N의 관계 : 관계 이름으로 된 새로운 테이블을 만들되, 관계에 관련되는 개체 두개의 각각의 일차키와 관계 자체의 속성을 테이블의 포함시킨다. 이때 관계에 대응하는 테이블의 일차 키는 개체 두개의 일차 키를 더한 것이다.