Relational data model | (옜날방식)Network data model/Hierarchical data model |
---|---|
relation | table |
tuple | record, row |
attribute | column |
각 속성 도메인 값의 모든 조합 (쉽게 말해 특정 시점에 테이블의 상태)
즉, 도메인의 Cartesian product의 부분 집합(아래에 설명)
을 attributes라고 하면 이 관계스키마
을 에 대한 Domain이라고 하면 관계인스턴스는 의 부분집합이다.
또는 n-tuples의 집합이다.()
Integrity constraints : 키 제약(Key constraint : primary key는 중복된 값을 가지지 못하는 제약), 엔티티 제약(Entity constraint : primary key는 NULL값을 가지지 못하는 제약), 참조 무결성 제약(Referential integrity constraint : foreign key는 NULL이거나 참조 릴레이션의 primary key 값과 동일해야 하는 제약) 등
key는 3가지 종류가 있다 :
Super Key(수퍼키)
릴레이션에서 튜플을 유일하게 식별할 수 있는 속성의 집합
e.g., 이름은 수퍼키 될 수 ❌, 학번은 수퍼키 될 수 ⭕,
이름+학번도 수퍼키될 수 ⭕
가장 큰 수퍼키는 Relation
Candidate Key(후보키)
Primary Key(기본키)
기본키 ⊂ 후보키 ⊂ 수퍼키
My student라는 relation이 student-id, name, national-id, address, phone이라는 attribute를 갖고있다고 가정하자.
여기서 하나도 겹치지 않는 유일한 속성은 student-id, national-id(신분증)이다.
상기와같이 2개의 테이블이 있고, student의 major컬럼은 department의 dID를 참조하고 있는 외래키이다. 살펴보면, student 테이블에서 Lee 학생의 major속성 값은 2이며, 이는 department 테이블을 보면 electrical engineering을 전공하고 있음을 알 수 있다.
그러나 Sohn 학생은 major 속성 값 4에 대응이 되는 학과가 없어 문제가 있다. Park 학생은 major 값이 없는 null 값인데, 아직 학과가 결정되지 않았거나 또는 데이터가 존재하지 않거나 등으로 해석할 수 있어, 문제가 있는 것은 아니다.
즉, major속성 값은 아무런 제약 없이 임의의 값을 가질 수 없고, department의 dID 속성 값 중에서 나와야 의미가 있다. 이 경우, major 속성을 department(dID) 참조하는 외래 키(foreign key)라고 하며,student 테이블을 참조하는 테이블, department 테이블을 참조 받는 테이블이라고 한다.
참조 받는 속성은 반드시 그 테이블의 기본키이어야하며, 본 예제서도 dID가 department 테이블의 기본키임을 알 수 있다. 이는 student 관계의 특정 튜플과 department 관계의 특정 튜플이 관련이 있을 때(상기에서는 학생과 학과 간의 ‘전공’ 관계), department 관계의 primary key를 참조하여야 하기 때문이다. department 의 primary key를 참조하여야만, 반드시 department 관계의 하나 튜플이 특정된다.
또한 department 테이블의 <3,media> 튜플을 참조하는 튜플이 student 테이블에 없으며, 이는 참조 무결성 제약과 관련 없이 허용되는 현상이다.
데이터 사전은 데이터베이스 시스템이 내부적으로 관리하는 데이터 장소이며, 데이터에 대한 데이터 즉 메타데이터를 관리한다.
데이터 사전이 저장 및 관리되는 데이터 상세는 다음과 같다 :
상용 데이터베이스 시스템은 사용자에게 투명하게 데이터 사전 접근을 허용하며, 사용자는 SQL 언어를 활용하여 데이터 사전에 속하는 데이터를 접근할 수 있다.
상기 그림은 대학교 데이터베이스를 스키마 다이어그램으로 표시한 것이다. 앞으로 본 책에서 언급되는 대부분 예제는 위의 대학교 데이터베이스 스키마를 사용하므로, 학생들은 이 다이어그램을 숙지하길 바란다.
각 테이블에 대한 예제 인스턴스는 다음과 같다. 예제 인스턴스는 테이블에 대한 이해 향상에 도움을 주려고 하는 것이며, 향후에 나오는 예제들이 예제 인스턴스를 가정하고 설명하지는 않는다.
CREATE TABLE `Customer` (
`customer_id` varchar(10),
`customer_name` varchar(10),
`customer_street` varchar(50),
`customer_city` varchar(10),
PRIMARY KEY (`customer_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
CREATE TABLE `Loan` (
`loan_number` varchar(10),
`amount` int,
PRIMARY KEY (`loan_number`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
CREATE TABLE `Account` (
`account_number` varchar(10),
`balance` int ,
PRIMARY KEY (`account_number`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
CREATE TABLE `Branch` (
`branch_name` varchar(10) ,
`branch_city` varchar(10) ,
`assets` int ,
PRIMARY KEY (`branch_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
CREATE TABLE `Payment` (
`loan_number` varchar(10) ,
`payment_number` varchar(10) ,
`payment_amount` int ,
`payment_date` date ,
PRIMARY KEY (`loan_number`, `payment_number`),
FOREIGN KEY (`loan_number`) REFERENCES Loan (`loan_number`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
CREATE TABLE `Borrower` (
`customer_id` varchar(10) ,
`loan_number` varchar(10) ,
FOREIGN KEY (`customer_id`) REFERENCES Customer (`customer_id`),
FOREIGN KEY (`loan_number`) REFERENCES Loan (`loan_number`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
CREATE TABLE `Depositor` (
`customer_id` varchar(10) ,
`account_number` varchar(10) ,
`access_date` date ,
FOREIGN KEY (`customer_id`) REFERENCES Customer (`customer_id`),
FOREIGN KEY (`account_number`) REFERENCES Account (`account_number`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
CREATE TABLE `Loan_Branch` (
`loan_number` varchar(10) ,
`branch_name` varchar(10) ,
FOREIGN KEY (`loan_number`) REFERENCES Loan (`loan_number`),
FOREIGN KEY (`branch_name`) REFERENCES Branch (`branch_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;