여기서는 외우기 좋은 상태로 이해하는 것에 목적을 두도록 하겠다. 자세한 설명은 Reference 를 참고하도록 하자.
객체 Object
교수
|
과목명
|
안철소 |
IT경영 |
안철소 |
컴퓨터 보안 |
| 박근애 | 정치와 대중 |
직접 DB modeling 을 한다고 생각하자. 여기서 하는 모델링은 최종적으로 DBMS 의 table 을 생성하기 위함이다라는 전제하에 이야기를 풀어나가겠다. 우리는 이제 대학에서 학생들이 수강신청할 때 보는 어떤 선생님이 어떤 과목을 하는지가 나와있는 표를 작성할 때 사용할 db 를 만든다고 생각하자. 그러면 무엇이 필요하겠는가? 당연히 “교수” 라는 존재와 "과목” 이라는 존재이다. 이 존재를 사각형으로 표현하자. 이것이 흔히 이야기 하는 객체가 된다. 우리의 모델링은 여기서 시작하자.
여기서 왜 “수강신청표”라는 녀석을 객체로 만들지 않느냐고 할지도 모르겠다. 사실 우리의 db는 학교에서 사용하는 것으로 가정해서 “수강신청표”외에 다른 곳에서도 쓰일 것을 암묵적으로 가정하고 하는 것이라 그렇다. 단순하게 “수강신청표”만 필요하다면 굳이 db 를 만들 이유도 없지 않겠는가?
“Teacher”, “Course”
속성 Attribute
여하튼 우리는 이제 “교수”와 “과목”이라는 객체를 얻었다. 여기서 무엇을 더해야 하는가? “교수”나 “과목” 이라는 객체를 살펴보자. 이 “교수”, “객체”는 우리가 만들려는 수강신청표의 머릿글의 역할 밖에 하지 않는다. 우리는 “수강신청표”의 내용인 “안철소”, “박근애” 등의 이름을 넣어야 한다. “과목”에서는 “IT경영”, “컴퓨터보안”, “정치”등의 과목이름을 넣어야 한다. 이런 “이름”을 넣는 곳이 필요하다. 이 때 우리는 “이름” 이라는 “속성(Attribute)”를 추가하는 것이다.- Teacher
- Name
- Course
- Name
- CREATE TABLE "teacher"(
name TEXT NOT NULL,
) ; - CREATE TABLE "course"(
name TEXT NOT NULL,
) ;
SELECT teacher.name, course.name FROM teacher, course
관계 Relation
그러면 아마 DBMS에 따라 다르겠지만, “교수님 이름”과 “과목명”이 다르게 묶여서 나오는 경우가 발생할 것이다. 당연하게도 기계는 어떤 교수님이 어떤 과목을 담당하는지 모르기 때문에 정말 기계적으로 가져다 뿌려줄 뿐인 것이다. 그런데 우리는 “교수님 이름”과 “과목명” 사이의 “관계” 에 관한 정의를 내려놓지 않았다. 다시 말하면 두 개의 객체가 어떤 연관성이 있는지를 dbms 에 알려주지 않았기 때문에 이 멍청한 컴퓨터는 자기 멋대로(물론 이것도 정해져 놓은 것이지만
) 보여주는 것 뿐이다.우리는 이 관계에 대해서 다시 정의를 내려 주어야 한다. 그래야만 우리가 원하는 “수강신청표”를 만들 수 있기 때문이다. 그럼 우리는 teaches 라는 “관계”에 해당하는 녀석을 하나 만들자, 이 녀석을 사실 “수강신청표” 라는 객체를 만들어서 객체와 객체간의 관계로 표현해도 큰 무리는 없을 것 같다. 하지만 저 아래 만들어 놓은 ER diagram(Ref. 1 참고) 에 조금 껴 맞추기 위해서 우리는 “관계”를 정의하도록 하자.
제한 Restriction
관계도 RDMS 에서는 하나의 table 로 표현하면 된다. 우리는 “teaches”라는 이름의 테이블을 하나 만들고 나서 “teacher"와 “course” 라는 field 를 만들어서 해당하는 값을 써 넣으면 된다. 이 table 이 바로 “수강신청표”이다. 하지만 다른 점이 있다면, “수강신청표”는 대부분의 경우 고정돼서 더 이상 수정이 필요하지 않을 때 발표하는 최종 결과물이라고 한다면 이 “teaches” 라는 table 은 과목에 담당교수님이 바뀌거나 할 때 값을 수정하거나(update), 아예 강의가 사라질 때 값을 뺄(drop) 수 있는 녀석이라는 것이다. 그래서 이 teaches 라는 table 에는 제한(restriction) 이 들어가게 된다.이런 제한의 종류 중 대표적인 것이 connectivity 에 대한 제한과 cardinality 가 있겠다.(Ref. 3 참고) 이런 제한들이 CREATE TABLE 에서 할 수 있게 대부분의 DBMS 에서 제공한다.(Ref. 5) 예를 들면 아래와 같다.
CREATE TABLE distributors (이런 것들을 그림(diagram) 으로 표현하는 방법중에 하나가 ER-Diagram 이다. 이 다이어그램을 잘 알아두면 위에서 하는 것과 같은 복잡한 SQL 문을 외우고 사용하지 않아도 된다. 물론 자신이 직접 구현하는 경우라면 외우는 것이 여러모로 편리하겠지만 말이다 ;)
teacher integer CHECK(COUNT(teacher) < 3),
course integer UNIQUE
);
Reference
- wikipedia 개체-관계 모델(Entity-Relation Diagram)
http://ko.wikipedia.org/wiki/%EA%B0%9C%EC%B2%B4-%EA%B4%80%EA%B3%84_%EB%AA%A8%EB%8D%B8 - 데이터베이스 모델
http://hanbitbook.co.kr/web/sample/1423/database_chapter3.pdf - 개체-관계 모델 구성요소 설명 4 - 카디낼리티(Cardinality)
http://powerdesigner.tistory.com/entry/%EA%B0%9C%EC%B2%B4-%EA%B4%80%EA%B3%84-%EB%AA%A8%EB%8D%B8-%EA%B5%AC%EC%84%B1%EC%9A%94%EC%86%8C-%EC%84%A4%EB%AA%85-4-%EC%B9%B4%EB%94%94%EB%82%A0%EB%A6%AC%ED%8B%B0Cardinality-%EC%84%9C%EB%B8%8C%ED%83%80%EC%9E%85 - 데이터베이스 모델링
http://sjs0270.tistory.com/entry/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EB%AA%A8%EB%8D%B8%EB%A7%81 - CREATE TABLE Statement diagram
http://wiki.eeng.dcu.ie:8888/ee557/g2/560-EE.html#dsy560-EE_createtable
댓글 없음:
댓글 쓰기