다다

개체집합(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)

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

   릴레이션 (relation) 

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

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

   튜플 (tuple)

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

   에트리뷰트(attribute)

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

   디그리(degree)

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

   카디널러티(cardinality)

튜플들의 수를 말한다. 

  외래키란 다른 테이블에서 일차키인 속성의 집합이 주어진 테이블이 있을때, 이 속성의 집합을 주어진 테이블에서 외래키라고 한다. 말로는 어려운듯 하지만 보기를 보면 쉽게 알수 있다.  일단 키를 구성하는 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의 관계 : 관계 이름으로 된 새로운 테이블을 만들되, 관계에 관련되는 개체 두개의 각각의 일차키와 관계 자체의 속성을 테이블의 포함시킨다. 이때 관계에 대응하는 테이블의 일차 키는 개체 두개의 일차 키를 더한 것이다.

  자료 정의어(DDL: data definition language)

  자료 정의어는 스키마를 정의하는 언어이다. 스키마 정보는 자료 사전(data dictionary, 또는 자료 목록(= data directory)이라고도 함)에 들어 있다. 스키마 정보란, 자료(보기: 아이디, 패스워드 등)에 대한 자료(보기: 아이디의 자료형은 char이고 몇자리의 char인지)인데, 이를 메타데이터(metadata)라고 보통 부른다.

  SQL에서 자료 정의어의 보기를 들면 다음과 같다.

  create table 유저 {순서 인덱스 char(7), 아이디 char(10), 패스워드 char(15), 보유 캐릭터 개수 int };  

   자료 조작어(DML: data manipulation language)

   자료 조작어는, 데이터베이스 안에 있는 자료를 가져오거나(retrieve), 없에거나(delete) 바꾸거나(update), 데이터 베이스에 새 자료를 넣는(insert)일을 한다.

   SQL에서 자료 조작어의 보기를 들면 다음과 같다.

select * 

from 유저

where 아이디 = ’홍길동’; 

insert into 유저

values ('9902101' ’ 흥길동’); 

delete 

from 유저 

where 아이디 = 홍길동’? 

update 유저 

set 아이디 = '장길산’ 

where 아이디 = 홍길동’ ;

  자료 조작어의 성질 : 비절차적, 집합 결과

  자료 조작어의 성질을 말할때 책에 따라서 풀이가 좀 달라서 혼란스러운데 다음과 같이 두가지 독립적인 기준에 나눌수 있으며, 그 결과 2*2의 네가지 로 나눌 수 있다.

  첫째 절차적인지 (procedural) 비절차적인지 (non - procedural)

  우리가 많이 쓰는 c 등의 고급프로그래밍 언어는 거의 모두 절차적이다.

  int a = 0; 이런 문장은 정수형 a를 선언하여 메모리 상에 올리고 거기에 0을 대입하는 절차적인 과정을 거친다.

  절차적인 자료 조작어로는, 뒤에서 배우게 될 관계 대수 (relational algebra), 그리고 계층적 모델과 네트웍 모델에서 쓰는 자료 조작어가 있다.

  비절차적 언어로는 관계 해석(relational calculus)가 있으며, 또한 관계 해석을 많이 채택한 SQL에서도 비절차적 면을 볼수 있다.(SQL은 관계 해석과 관계 대수 두가지에 바탕을 두고 있다.) 

  비절차적 언어의 특징을 살펴보면, 보기를 들어 유저, 아이디, 캐릭터라는 속성으로 이루어진 유저라는 테이블이 있을때 유저 테이블의 스키마와 인스턴스가 아래와 같다면

   유저   순서인덱스    아이디    캐릭터

0000000001   ID1          전사

0000000002   ID2          전사

0000000003   ID1          마법사

0000000004   ID2          마법사

   이테이블에서 캐릭터가 마법사인 유저의 아이디를 찾아내라고 한다면 절차적 언어에서는  FOR문등으로 반복을 돌면서 찾게 될 것이다.

  그에 비해서 비절차적 언어인 SQL을 쓴다면 어떤 철자적인 내용에 대해서는 말하지 않고 다음과 같이 쓸것이다.

  select 순서인덱스

  form 유저

  where 캐릭터 = "마법사"

  둘째, 자료 조작어의 명령 결과로 한번에 레코드가 한개(recored-at-a-time)씩 나오는지 아니면 여러개의 자료(자료의 집합)가 한꺼번에 나오는지 (set-at-a-time)에 따라서 두가지로 나뉜다.  조합해 보면 다음과 같다.

  비절차적 한개씩 (이녀석은 별로 없다고 한다)

  비절차적 자료집합 (관계 해석 SQL)

  절차적 한개씩 (계층적 모델, 네트웍모델)

  절차적 자료집합 (관계 대수)

  질의어(query language)와 자료 조작어(DML)

  질의어(쿼리)라는 낱말은 원래 뜻은 물어보다이며 데이터 베이스와 관련하여서는 이미 있는 자료나 정보를 가져오는 것이다. SQL에서 보면 select만 해당되고 insert, delete, update는 해당되지 않는다.

  이에 비해, 자료 조작어(DML)는 이미 있는 자료를 가져오는 것뿐만 아니라, 있는 자료를 지우거나 고치는 것과, 새 자료를 넣는 것까지 할수 있으므로 질의어 보다 더 넓은 개념이다. SQL에서 보면 select, insert,delete, update를 모두 포함하는 개념이다.

  그렇지만, 오늘날 실제로 질의어라는 용어를 원래의 뜻대로 있는 자료를 가져오는 것에 국한하여 쓰는 일은 아주 드물다. 거의 모든 사람들은 쿼리문을 자료 조작어와 맞바꾸어 쓸수 있는, 뜻이 같은 용어로 본다. 낱말의 원래 뜻을 생각하면 잘못된 용법이지만, 오늘날 거의 모든 사람들이 이렇게 하므로 그냥 관습을 따를 수 밖에 없다고 본다.

  데이터 베이스 관리자(DBA: Database Administrator)

  데이터 베이스 관리자는 데이터베이스 관리 시스템을 관리할 뿐만 아니라, 데이터베이스, 그리고 그 기관에서 개별된 응용 프로그램을 관리한다. 작은 기관의 경우에는 한사람이 관리자 일을 할 수도 있을 것이고, 큰 기관에서는 관리자의 일을 여러 사람이 맡게 된다.

  관리자는 그 밖에도 자료 접근 권한을 정하고 바꾸는 일, 무결성 제약 조건을 정하는 일을 한다.

  데이터 베이스 사용자

  데이터 베이스 사용자의 종류는 너무 많고, 또한 나누는 기준에 따라 다르지면 몇가지 종류를 보자면

  응용프로그래머 : 주어진 데이터베이스 관리시스템을 써서 그 기관에 필요한 응용프로그램을 만든다. 게임을 만드는 프로그래머도 이에 속한다. 이 경우 보통의 SQL(이른 바 상호 작용적 SQL: interactive SQL)을 바로 쓰기보다는 주로 내포된(embedded) SQL을 많이 사용한다.

  일반사용자 : 만들어진 응용프로그램을 쓰는 사람인데, 실제로 이런사람이 엄청 많다. 뭐 그냥 실생활에 쓰이는 대부분을 보면 된다. 우리 자신들 이니까.

  4GL 운영체제

  4GL(fourth generation language)

  4GL 데이터베이스를 다루기 위하여 쓰는 언어 가운데 4GL이라는 것이 있다. 

  제 1세대 언어는 1GL(first-generation language)라고 하며 기계어(machine langage)가 여기에 속한다.

  제 2세대 언어는 어셈블리 언어

  우리가 쓰는 c같은 고급언어를 3세대 언어라고 한다.

  4GL이란 3GL보다 한단계 더 높다고 보다는데, 일반적으로 데이터베이스 환경에서 양식을 만들거나 화면에 자료를 보여주는 프로그램을 쉽게 짤 수 있게 해주는 것이 4GL의 주요 기능이다. 그런데 SQL은 표준화가 잘되어있어서, SQL 프로그램이 다른 데이터베이스 관리 시스템에 옮겨가더라도 별 어려움 없이 잘 돌아간다. 하지만 4GL은 표준화가 전혀 되어 있지 않아서, 다른 데이터 베이스 관리 시스템에 옮겨가서 쓸 수가 없다는 단점이 있다.

  데이터 베이스 관리 자체(DBMS)  와 운영 체제(OS)

  운영 체제의 관점에서 보면 데이터베이스 관리 시스템은 어디까지나 하나의 응용프로그램이므로, 데이터베이스 관리 시스템은 운영체제 위에서 돌아간다. 위에서 돌아간다고 해서 데이터베이스 관리시스템이 운영체제를 관리한다는 것은 아니다. 운영체제가 데이터베이스 관리 시스템을 통체한다.

  일반적으로 파일을 처리하는 응용프로그램의 경우, 응용 프로그램에서 운영체제의 파일관리자를 통하여 파일을 처리하게 된다. 그런데 데이터베이스 응용프로그램은 파일의 내용을 바꾸려면, 먼저 데이터베이스 관리시스템에 이를 요청하고, 데이터베이스 시스템은 다시 운영체제의 파일 관리자를 통하여 파일을 처리하게 된다.

데이터 베이스에서 뷰란?

  뷰(=view)는 가상 테이블(=virtual relation)이라고도 한다.

자료의 추상화(data abstraction) 세 단계

  데이터베이스 관리 시스템과 사용자 사이의 상호 작용을 쉽게 풀이하기 위하여 데이터베이스의 자료를 추상화하며, 보통 다음과 같이 세 가지 수준으로 나눈다.

  하지만 이는 개념모델(reference model)이다. 즉 꼭 따라야 하는 것은 아니며 데이터 베이스의 모든 시스템이 이 모델에 의하여 구성된 것은 아니다.

  이는 마치 데이터통신에서(ISO OSI의 일곱 단계 통신모형에 맞는 통신 프로그램이 거의 없는 것이나 마찬가지이다.)

  1) 물리적 수준(physical level)

  자료가 실제로 저장되는 수준이며, 가장 아래 수준이다.

  2) 논리적 수준(logical level)

  이것은 데이터베이스 관리자(DBA : database administrator)이 처리하는 수준이다.

  3) 뷰(=가상 테이블) 수준(view level)

  일반 사용자가 쓰는 수준으로 볼 수 있다. 이런 것이다. 데이터란 결국 바이트단위로 처리를 하게 되는데. 이는 기계어로 보면 왠만해서는 알아볼 수 없다.

  하지만 문서처리 프로그램중 엑셀프로그램 처럼 도표로 사용자가 볼 수 있고 권한에 따라서 필요한 부분만 수정할 수 있다면? 이런 부분이 바로 view 수준이라고 한다.

  그런데 실제 상용 데이터베이스 관리 시스템에서 어떤 명령이 어느 수준에 해당하는지 명확하게 나누는 것은 쉽지 않다. 뷰 수준은 그런데로 쉽게 알 수 있지만 물리적 수준과 논리적 수준은 때때로 경계가 모호하다. 하지만 앞서 말했듯 위의 세가지 모델은 어디까지나 참조 모델일 뿐이므로, 구체적인 어떤 사용 데이터베이스 관리 시스템의 명령을 세단계로 나누는 문제에 너무 매달리지 말자.

자료의 독립성(data independence)

  일반적으로 자료의 독립성이란 어느 단계의 스키마를 바구었을 때, 그 위 단계의 스키마에 영향을 주지 않고 결국 응용 프로그램에 영향을 주지 않는 것을 가리킨다.

  c++로 친다면 클래스 간의 의존성 제거 객체지향적으로보면 리스코프 치환법칙과 의미가 통한다.

  자료의 독립성은 다음과 같이 두가지로 나타나게 된다.

  1) 물리적(physical) 자료 독립성

  맨 아래 단계인 물리적 스키마를 바꿔도, 그 위 단계인 논리적 단계 스키마에 영향을 주지 않는 것을 가리킨다. 당연히 논리적 스키마에 영향을 주지 않으므로 그 위 단계인 뷰 단계의 스키마에는 물론 영향을 주지 않는다.

  여기서 잠깐! 스키마란?

  데이터베이스 스키마(database schema)는 데이터베이스에서 자료의 구조, 자료의 표현 방법, 자료 간의 관계를 정의한 것을 말하는 전산학 용어이다. 데이터베이스 관리 시스템(DBMS)이 주어진 설정에 따라 데이터베이스 스키마를 만들어 내며, 데이터베이스 사용자가 자료를 저장, 조회, 삭제, 변경할 때 DBMS는 그것이 생성한 데이터베이스 스키마를 참조하여 명령을 수행한다.

  2) 논리적(logical) 자료 독립성.

  가운데 단계인 논리적 단계의 스키마를 바꿔도 그 윗 단계인 뷰 단계의 스키마에 영향을 주지 않는 것을 가리킨다. 뷰 단계 스키마에 영향을 주지 않기 때문에, 그 결과 응용 프로그램에도 영향을 주지 않는다.

  이때 이 두가지 독립성 단계에 대해서 제대로 설명하지 않는 부분이 많은데 그 이유는 상용 데이터 베이스 관리 시스템에서 물리적 단계와 논리적 단계를 나누기가 쉽지 않기 때문이다.

  하지만 SQL명령어 적으로 예를 들어 보겠다.

  create table 유저 {순서인덱스 cahr(7), 아이디 cahr(20)};

  위의 create table 명령은 순서인덱스와 아이디이라는 속성으로 이루어진 학생이라는 테이블을 만든다. 그 뒤 아래에 select 명령을 쓰면, 아이디가 '홍길동'이라는 유저의 이름을 보여준다.

  select *

    form 유저

    where 아이디 = '홍길동';

  자료의 독립성에 관한 구체적인 첫번째 보기는 색인(= 찾아보기, index)이다. 색인이 있으면 검색속도가 빨라지게 되는데.

  보기를 들어 유저수가 10000명인데 유저자료가 아이디 순서대로 간추려져 있다면 이름에 대한 색인이 없다고 한다면 create index 명령을 써서 이름에 대한 색인을 만들어 둔뒤 '홍길동'을 찾으면,색인이 없을 때보다 검색 속도가 훨씬 빨라진다.

  create index 이름_색인

  on 학생(이름);

  select *

  form 유저

  where 아이디 = '홍길동';

  그런데, 여기서 중요한 것은 색인이 새로 만들어 지더라도, 위의 select 명령을 전혀 바꾸지 않고 꼭 같은 결과를 얻을수 있지만, 색인이 있든 없든, select 명령은 바뀌지 않고 그대로 이고, 다만 실행 속도가 달라질 뿐이다.

  자료 독립성에 관한 구체적인 둘째 보기는 뷰에 관한 것이다. 보기를 들어, 아래와 같이 순서 인덱스, 아이디, 패스워드로 이루어진 유저이라는 테이블이 있고, 학생이라는 테이블에서 create view 명령을 써서, 학번과 이름만으로 이루어진 학생_view라는 뷰를 정의했다고 하자

  create table 유저 {순서 인덱스 char(7), 아이디 char(10), 패스워드 char(15)};

  create view 유저_view as

   select 순서 인덱스, 아이디

     from 유저;

  이렇게 하면 응용 프로그램에서는 유저_view라는 뷰를 다음과 같이 쓸 수 있다.

  select *

    from dbwj_view

    where 순서인덱스 = '9902101';

  그런데 학생에 휴대전화라는 속성이 하나 더 들어가서 유저의 스키마가 다음과 같이 바뀌었다고 하자.

  유저 {순서 인덱스 char(7), 아이디 char(10), 패스워드 char(15), 휴대전화 char(15)};

  유저의 스키마가 이렇게 바뀌더라도 결국 유저_view를 정의하는 create view 명령을 바꿀 필요가 없으며, 또한 유저_view를 쓰는 응용프로그램에서 select 문장을 전혀 바꾸지 않아도 결과는 제대로 나온다. 유저의 스키마가 바뀌었지만, 유저_view의 정의를 바꿀 필요가 없으며, 유저_view 뷰를 쓰는 응용프로그램에서 SQL문장을 전혀 바꿀 필요가 없다.

  이를 고급프로그래밍 언어 C++에서 처리한다고 생각해보자.

found=0 ; 

for 0=1; (= num_records ; i++) { 

read from 유저_view 순서인덱스 , 아이디) ; 

if (아이디 = 홍길동’) { 

printf (학번, 01 름) ; found++ ; 

} // endif 

} // end for 

if (tound == 0) 

  printf 홍길동 학생이 없습니다 ) ;

식으로 짜며 당연히 다형성이나 그때그때 필요한 코드를 또다시 짜야만 할것이다.

물론 이런 것을 감안하고 프로그래밍 할 수는 있지만 그것은 이미 존재하는 데이터 베이스 시스템과 같은 역할을 하는 파일입출력 프로그램을 고급언어로 다시 짠다는 것인데 엄청난 노력과 시간이 들어가게 될 것이다.

스키마(schema)와 인스턴스(instance)?

  데이터 베이스와 관련하여 스키마와 인스턴스는 구별되어야 하는데 관계형 데이터 베이스의 경우에는 관계(= 테이블, relation)와 데이터베이스 각각에서 스키마와 인스턴스 개념이 적용된다. 다시 말하여 테이블의 스키마와 테이블의 인스턴스가 존재하며 또한 데이터 베이스의 스키마와 데이터베이스의 인스턴스라는 개념이 존재한다는 것이다.

  관계형 데이터베이스 환경에서 관계의 스키마와 관계의 인스턴스를 비교해보자. 아홉 자리를 차지하는 순번 인덱스이라는 속성(attribute), 스무 자리를 차지하는 아이디이라는 속성, 그리고 열 다섯 자리를 차지하는 패스워드라는 속성으로 이루어진 학생이라는 관계를 만드는 SQL 문장 create table가 아래에 나와있다.

  create table 유저 {순서 인덱스 char(7), 아이디 char(10), 패스워드 char(15)};  

  이 문장은 학생이라는 테이블에 어떤 속성(순서 인덱스, 이름, 집전화)가 있으며, 각 속성의 자료형(data type)가 무엇인지만 나타낸다. 다시 말하면 테이블의 틀(=뼈대)을 나타낼 뿐, 그 테이블 안에 어떤 자료가 실제로 들어있고 어떤 식으로 데이터베이스의 로직이 이루어지는지는 알수가 없다.

  이처럼 테이블에 있어서 속성 이름과 자료형 등에 관하여 규정하는 것을 관계(=관계)의 스키마라고 한다. 위의 create table라는 SQL 명령은 학생이라는 테이블(=관계)의 스키마를 만드는 명령이다.

  위에 설명한 단어의 원론적인 설명과 다르게 데이터베이스에서 스키마(SCHEMA)는, 틀, 뼈대 등의 뜻이 있으며 보통 한글로 옮기지 않고 스키마라는 용어를 그대로 사용한다.

  데이터 베이스는 일반적으로 도표형식으로 내용을 볼 수 있는데.

  유저   순서인덱스    아이디    패스워드

0000000001   ID1        23451123

00000000012   ID2       123456

  이런식으로 어떤 특정 시점에 테이블 안에 있는 구체적인 값의 집합을 관계(=테이블)의 인스턴스라고 한다.

  그런데 일반적으로 테이블의 스키마는 처음 만들 때 잘 생각해서 만들기 때문에, 일단 스키마를 한번 만들면 잘 바꾸지 않는다. 거기에 비해서 테이블의 인스턴스는 상대적으로 스키마보다는 많이 바귀게 된다.

일단 스키마가 바뀌는 경우를 보도록 하자. 

• 현재 있는 학번, 이름, 집전화 속성 가운데 어떤 속성을 빼기 . 

보기 . 패스워드를 뺀다

  create table 유저 {순서 인덱스 char(7), 아이디 char(10)};  

·현재 없는 속성을 더 넣기 . 

보기 : 보유 캐릭터 개수를 더 넣는다. 

  create table 유저 {순서 인덱스 char(7), 아이디 char(10), 패스워드 char(15), 보유 캐릭터 개수 int };  

휴대전화 char(15)); 

• 속성의 자료형을 바꾼다, 

보기: 패스우드의 자료형을 char(15) 에서 char(20) 로 바꾸었다. 

  create table 유저 {순서 인덱스 char(7), 아이디 char(10), 패스워드 char(20), 보유 캐릭터 개수 int };  

  당연히 데이터 베이스의 테이블이 많아질수록 수많은 유저들의 정보가 통채로 입력되므로 그에 맞는 정보를 입력해줘야 한다. 유저수가 많으면 많을 수록 보통 번거로운 것이 아닐 것이다. 거기에 비해서 테이블의 인스턴스는 상대적으로 많이 바뀌지 않는다. 인스턴스가 바뀌는 경우에 대해서 예를 들어본다면

  유저가 한명 추가되어 맨 마지막줄에 새로운 유저가 들어오는 경우.

  혹은 한명의 유저의 패스워드가 변경된 경우.

  이외 등등등.

  과 같은 경우 인스턴스가 바뀌었다고 하는데. 일반적으로 테스블의 한 행이 바뀌거나, 추가되거나, 삭제되면 인스턴스가 바뀐다고 하며 예상해봐서 알겠지만 당연히 인스턴스는 자주 바뀐다.

  자료 모델?

  데이터베이스에서 자료를 나타내는 방식은 여러가지가 있으며, 책에 따라 나누는 기준이나 방법도 다르다. 

  어떻게 나누냐는 덮어 두고 실제 쓰여졌던 데이터 베이스의 모델들에 대해서 알아보겠다.

  개체 - 관계모델(E-R : entity - relationship model)

  개체 - 관계 모델은 데이터베이스 설계(data base design) 때 많이 쓰인다. 그렇지만 개체 - 관계 모델에 따른 데이터 베이스 관리 시스템 프로그램이 개발되어 있지 않기 때문에, 실제 자료를 처리하기 위하여 우리가 개체 - 관계 모델을 쓰지는 않는다.

   개체 관계 모델은 실제 세계에 대한 인식을 바탕으로 한다 객체지향프로그래밍과 닮은 방향성을 가지고 있어 보인다. 이 모델은 첫째, 개체(entity), 둘째 개체와 개체 사이의 관계(relationship), 이 두가지를 기본으로 하고 있어서 개체 - 관계 모델이라고 부른다.

  개체란, 학생, 과목, 은행 계정, 회사 등과같이 실제 세상에 있는 객체를 가리키며, 각 객체는 다른 객체와 구별된다. 개체는 하나 또는 여러개의 속성으로 나타내게 된다. 유저를 패스워드 순서 인덱스 아이디라고 나눈 것과 같다.

  이에 쓰이는 용어는 개체 집합, 관계 집합, 개체 사이의 사상(=매핑) 크기(mapping cardinality) 제약, 개체 - 관계 모델 그림 (diagram) 등이 있다.

  객체지향 모델(OO model, object - oriented model)

  객체지향 모델은 개체-관계 모델을 수용하고 거기에 실행할 수 있는 프로그램까지 모두 포함한다.

  관계형 모델 (relational model)

  관계형 모델은 오늘날 가장 널리 쓰이고 있는 관계형 데이터베이스의 바탕이 되는 모델이다.

  자료(data)를 나타낼 때, 그리고 자료사이의 관계(relationship)를 나타낼 때 모두 관계(relation, 또는 테이블 : table, 표)를 쓰기 때문에, 관계형 모델이라고 부른다. 관계형 데이터베이스는 1970 년대에 연구가 시작되어 오늘날 가장 널리 쓰고 있다.

  네트웍 모델(network model)

  관계형 모델이 나오기 전에, 네트웍 모델에 바탕을 둔 사용 프로그램을 1960년대 후반부터 썼지만, 요즘은 이 모델을 사용하여 제작되는 데이터 베이스는 거의 없다.

  계층적 모델(hierarchical model)

  관계형 모델이 나오기 전에 계층적 모델에 바탕을 둔 사용 프로그램을 1960년대 후반부터 썼지만, 요즘 새로만들 때 역시나 이 모델을 쓰는 곳은 거의 없다.