Oracle 필기(16) 데이터베이스 디자인 모범

데이터베이스 디자인 모델은 매우 중요한 개념이지만 이 중요도는 참고에만 적합하다.데이터베이스 디자인 모델을 사용하면 데이터 테이블을 더욱 잘 보존할 수 있다. 아무리 합리적인 디자인이라도 데이터의 양이 많으면 성능에 문제가 존재할 수 있기 때문이다.그래서 개발에서 유일하게 디자인의 보전이라고 할 수 있는 것은 디자인을 할 때 향후 프로그램에 다중 표 관련 조회가 발생하는 것을 최대한 피하는 것이다.
제1범례
이른바 첫 번째 범례란 데이터 표의 데이터 열을 다시 나눌 수 없다는 것을 가리킨다.
예를 들어 다음과 같은 데이터 테이블이 있습니다.

CREATE TABLE member (

　　mid NUMBER PRIMARY KEY,

　　name VARCHAR2(200) NOT NULL,

　　contact VARCHAR2(200)

);

이때 디자인한 것은 불합리하다. 연락처는 여러 가지 데이터로 구성되어 있기 때문에 전화, 주소, 이메일, 핸드폰, 우편번호가 맞지 않기 때문에 지금은 디자인을 수정할 수 있다.

CREATE TABLE member (

　　mid NUMBER PRIMARY KEY,

　　name VARCHAR2(200) NOT NULL,

　　address VARCHAR2(200),

　　zipcode VARCHAR2(6),

　　mobile VARCHAR2(20),

　　tel VARCHAR2(20)

);

하지만 이 안에는 두 가지 설명이 필요하다.

첫 번째, 성명에 대해 외국의 표 디자인에서 성명도 성과 이름 두 종류로 나뉘지만 중국에서는 성명 보존이다.

두 번째, 생일에 대한 전문적인 데이터 유형(DATE)이 있기 때문에 생일년, 생일월, 생일일로 설정할 수 없습니다.

불가분할이란 모든 데이터 유형이 데이터베이스로 제공된 각 데이터 유형을 가리킨다.
2. 두 번째 모델: 다대다
두 번째 모델: 데이터 테이블의 비관건 필드에 후보의 관건 필드에 대한 일부 함수 의존이 존재한다.
두 번째 모델은 두 가지 방식으로 이해된다.

이해1: 열 사이에 함수 관계가 존재하지 말아야 한다. 현재 다음과 같은 디자인이 있다.

CREATE TABLE orders (

　　oid NUMBER PRIMARY KEY,

　　amount NUMBER,

　　price NUMBER,

　　allprice NUMBER

);

현재의 상품 총가격(allprice) = 상품 단가(price)* 상품 수량(amount) 때문에 함수의 의존 관계가 존재한다.

이해2: 하나의 데이터 테이블의 디자인을 통해 한 학생의 수강신청 시스템을 완성하고 현재 첫 번째 모델에 따르면 다음과 같다.

CREATE TABLE studentcourse (

　　stuid NUMBER PRIMARY KEY,

　　stuname VARCHAR2(20) NOT NULL,

　　cname VARCHAR2(50) NOT NULL,

　　credit NUMBER NOT NULL,

　　score NUMBER

);

INSERT INTO studentcourse (stuid,stuname,cname,credit,score) VALUES (1,'  ','Java',3,89);

INSERT INTO studentcourse (stuid,stuname,cname,credit,score) VALUES (2,'  ','Java',3,99);

INSERT INTO studentcourse (stuid,stuname,cname,credit,score) VALUES (3,'  ','Java',3,78);

INSERT INTO studentcourse (stuid,stuname,cname,credit,score) VALUES (1,'  ','Oracle',1,79);

INSERT INTO studentcourse (stuid,stuname,cname,credit,score) VALUES (2,'  ','Oracle',1,89);

이러한 설계는 첫 번째 설계 패러다임에 해당하지만 두 번째 패러다임에는 해당하지 않습니다. 프로그램에 다음과 같은 오류가 발생하기 때문입니다.

데이터 중복: 학생과 과정의 데이터가 중복된 상태이고 가장 심각한 것은 메인 키의 설정 문제이다.

데이터 업데이트가 너무 많다. 만약에 현재 한 과목에 3000명이 참가했다면 한 과목의 학점을 변경할 때 3000개의 기록을 수정해야 하기 때문에 성능에 영향을 미칠 수 있다.

만약에 한 과정에 학생이 참가하지 않으면 이 과정은 학교에서 철저히 사라진다.

이 문제를 해결하려면 데이터 테이블의 설계를 다음과 같이 수정할 수 있습니다.

CREATE TABLE student (

　　stuid NUMBER PRIMARY KEY,

　　stuname VARCHAR2(20) NOT NULL

);

CREATE TABLE course (

　　cid NUMBER PRIMARY KEY,

　　cname VARCHAR2(50) NOT NULL,

　　credit NUMBER NOT NULL

);

CREATE TABLE studentcourse (

　　stuid NUMBER REFERENCES student(stuid),

　　cid NUMBER REFERENCES course(cid),

　　score NUMBER

);

INSERT INTO student (stuid,stuname) VALUES (1,'  ');

INSERT INTO student (stuid,stuname) VALUES (2,'  ');

INSERT INTO student (stuid,stuname) VALUES (3,'  ');

INSERT INTO course (cid,cname,credit) VALUES (10,'Java',3);

INSERT INTO course (cid,cname,credit) VALUES (11,'Oracle',1);

INSERT INTO course (cid,cname,credit) VALUES (12,'Linux',2);

INSERT INTO studentcourse (stuid,cid,score) VALUES (1,10,89);

INSERT INTO studentcourse (stuid,cid,score) VALUES (2,10,99);

INSERT INTO studentcourse (stuid,cid,score) VALUES (3,10,78);

INSERT INTO studentcourse (stuid,cid,score) VALUES (1,11,79);

INSERT INTO studentcourse (stuid,cid,score) VALUES (2,11,89);

이런 디자인은 앞서 설명한 운동회-종목-성적의 디자인과 같다.
셋째, 셋째 모델: 일대다
예를 들어 현재 한 학교에 여러 명의 학생이 있는데 만약에 첫 번째 모델로 실현할 수 없고 두 번째 모델로 하면 다대다의 관계를 나타낸다. 즉, 한 학교에 여러 명의 학생이 있고 한 학생이 여러 학교에 있으면 요구에 부합되지 않기 때문에 이때는 제3범식을 사용할 수 있다. 이전의 부서와 직원의 조작 실현을 참고하면 한 부서에 여러 명의 직원이 있다.그래서 디자인에 따라 다음과 같이 작성했다.

CREATE TABLE school (

　　sid NUMBER PRIMARY KEY,

　　sname VARCHAR2(20) NOT NULL

);

CREATE TABLE student (

　　stuid NUMBER PRIMARY KEY,

　　stuname VARCHAR2(20) NOT NULL,

　　sid NUMBER REFERENCES school(sid)

);

실제 작업 중 세 번째 모델의 사용이 가장 많다.
이상의 세 가지 범례는 단지 참고로 사용할 뿐이다.