"데이터센터 화재" 와 같이 뉴스에서, 혹은 온라인 게임의 오류로 인한 "데이터 롤백" 등, 우리는 실생활에서 "데이터" 라는 단어를 자주 접하죠. 여기서 나오는 데이터는 대개 데이터베이스(database)를 가리키는 말입니다.
데이터베이스란 서로 관련있는 어떤 데이터의 집합입니다.
그리고 그 데이터베이스를 관리하는 프로그램을 바로 DBMS(Database Management System) 라고 하며, 대표적인 DBMS로는 MySQL, MariaDB 등이 있죠.
데이터베이스와 DBMS 등, 데이터베이스와 연관 된 모든 것을 통틀어 데이터베이스 시스템이라 부릅니다.
또 데이터베이스로 만들어지기 전인 실제 세계의 정보를 mini-world 라고 합니다.
그렇다면 먼저 데이터베이스가 어떻게 이루어져 있는지 알아보겠습니다. 다음의 문장이 있습니다.
"@@@ 학생은 @@@ 학과에 소속되어 있다."
여기서 학생, 학과를 엔티티(Entity), 소속을 관계(Relationship) 이라고 합니다.
엔티티 사이의 관계를 그림으로 나타낸 것을 ER-Diagram, ERD 라고 합니다. ERD에 관해서는 다음 시간에 알아보도록 하겠습니다.
근데 여기서 엔티티 타입(Entity Type)과 관계 타입(Relationship Type)이라는 것이 등장합니다.
엔티티와 엔티티 타입, 관계와 관계 타입...? 다소 복잡하네요.
이 둘의 차이점을 말하려면 먼저 데이터베이스 설계 단계에 대해 간단히 짚고 넘어가야 합니다.
데이터베이스 설계 단계는 다음과 같이 크게 4단계로 나눌 수 있습니다.
1. 요구사항 분석 (SRS)
2. 개념 설계 (Conceptual Design)
3. 논리 설계 (Logical Design)
4. Physical Design, Index, Table space -> 최적화 (Optimization)
먼저 사용자가 개발자에게 mini-world와 요구사항(Requirements)을 제공하여 데이터베이스 설계를 요구합니다.
개발자는 주어진 mini-world와 요구사항으로 개념 설계를 하게 되는데, 이 때 쓰이는 것이 바로 ERD 입니다.
이렇게 만들어진 ERD로 상용 DBMS(MySQL, MaridDB)를 이용하여 테이블을 만들어 논리 설계를 합니다.
마지막으로 트랜잭션(Transaction), 내부 저장 구조(용량 조정 등), 인덱스, 접근경로, 화일 조직 등으로 성능 최적화를 하여 설계를 끝마칩니다.
그런데 이게 엔티티 타입이나 릴레이션 타입이랑 무슨 상관일까요?
다음 그림을 보겠습니다.
현실 세계에서 "@ 빌딩의 @ 강의실에서 @ 강의가 열린다." 라는 사실이 주어졌다고 합시다.
이 현실 세계의 사실이 바로 앞서 말한 mini-world죠. 또한 DB를 만들기 위해 사용자가 개발자에게 제공하는 것입니다.
빌딩, 강의실, 강의를 엔티티, 강의가 열린다는 사실을 관계라고 할 수 있습니다.
이 때 빌딩의 이름, 층, 강의실의 이름 등 각 엔티티에 여러 가지 특성들이 존재하겠죠?
개념 세계로 오면, 우리는 ERD를 작성하게 됩니다.
이 때 엔티티는 엔티티 타입으로, 관계는 관계 타입으로, 특성은 애트리뷰트(Attribute)로 변화합니다.
이를 컴퓨터 세계로 넘어가서 보면, 엔티티 타입과 관계 타입이 릴레이션(테이블)로 변화할 수 있습니다.
엔티티 타입과 관계 타입은 "테이블로 만들어질 수 있는 엔티티와 관계" 라고 할 수 있습니다.
그렇다면 테이블로 만들어지려면 어떤 조건이 있어야 할까요?
절대적으로 그렇다는 것은 아니지만, 애트리뷰트가 존재한다면 테이블로 만들어질 수 있습니다.
보통 엔티티에는 애트리뷰트가 존재하니 거의 모든 엔티티가 엔티티 타입, 즉 테이블로 만들어질 수 있습니다.
반면 앞서 설명한 "@ 빌딩의 @ 강의실에서 @ 강의가 열린다." 에서의 관계는 이렇다 할 애트리뷰트가 없어 보입니다.
이렇게 애트리뷰트가 없는 관계는 컴퓨터 세계에서 테이블 대신 PK-FK 라는 형식으로 각 엔티티의 사이를 맺어줍니다.
이에 대해 알아보기 전 튜플에 대해 짚고 가야 하는데, 튜플이란 본래 파이썬에서 쓰이는 자료구조 형태이지만,
데이터베이스에서의 튜플은 데이터에서 하나의 행을 의미하며, 한 객체를 의미한다고 보셔도 좋습니다.
애트리뷰트 중 튜플을 식별할 수 있는 것을 키(key) 라고 합니다.
예를 들어 한 튜플에 [김철수 / 980000-1000000 / 경기도 / 남성] 이 있다고 치면,
이 튜플을 식별 가능한 것(Unique 한 것)은 두 번째 애트리튜브인 주민번호가 되겠죠?
왜냐하면 김철수라는 동명이인이 있을 수 있고, 사는 곳과 성별 또한 Unique 하지 못하기 때문입니다.
PK-FK란 바로 Primary Key, Foreign Key를 말하는 것이고, 이 Key가 앞서 말한 키입니다.
추후 더 설명하겠지만 지금 간단히 짚고 넘어가자면, 빌딩과 강의실의 관계는 무엇이 있을까요?
바로 "@ 강의실은 @ 빌딩에 속해 있다"고 볼 수 있습니다.
그렇다면 강의실의 속성, 즉 애트리뷰트에는 "@ 빌딩에 속해있다는 사실"이 있겠네요!
이 때 빌딩의 키를 강의실의 키로 참조하여 둘의 관계를 맺어주는 것이 PK-FK라고 볼 수 있습니다.
추후 알아볼 MySQL에서 show tables; 명령어로 테이블을 불러올 수 있습니다.
여기서 building, class 등이 바로 테이블로 만들어진 엔티티 타입이라 할 수 있고,
student_has_class가 테이블로 만들어진 관계 타입이라고 할 수 있겠습니다.
스키마(Schema)란 데이터베이스에 대한 기술, 서술을 뜻합니다.
데이터베이스 스키마에는 앞서 말한 데이터, 엔티티, 릴레이션과 애트리뷰트, 제약(Constraints)이 담겨 있으며, 이렇게 만들어진 스키마에 삽입, 삭제 등 변화가 일어나면 스키마 진화(Schema evolution)가 일어났다고 합니다.
아래와 같이 스키마를 도식화한 것을 스키마 다이어그램(Schema Diagram)이라 합니다.
위의 스키마 다이어그램에서 Building, Room, Class는 테이블로 만들어진 엔티티 타입 입니다.
그런데 그 아래에 ID, Name 등의 요소가 보이시나요? 이를 애트리뷰트, 혹은 키라고 합니다.
여기서 Building의 ID와 Room의 Building_ID가 바로 앞서 설명한 PK-FK 관계라고 볼 수 있습니다.
<틀린 점이 있다면 지적 부탁드립니다. 감사합니다.>
'전공 > Database' 카테고리의 다른 글
| 데이터베이스 : 관계 모델과 제약 조건 (0) | 2022.10.25 |
|---|---|
| 데이터베이스 : EERD (Superclass, Subclass, Partial/Total, Disjointness/Overlap, 다중상속, Union) (0) | 2022.10.25 |
| 데이터베이스 : ERD #3 (애트리뷰트 유형, 관계 타입, NOT NULL, PK) (0) | 2022.10.24 |
| 데이터베이스 : ERD #2 (miniworld 실습, 역할 구분, 식별 관계) (0) | 2022.10.24 |
| 데이터베이스 : ERD #1 (ERD의 개념) (0) | 2022.10.23 |
최근댓글