데이터베이스프로그래밍 - 04. 정규화를 이용한 Database Design (04. Database Design Using Normalization)

Table Structure 평가

1. row 수 count / column examine(확인, 조사)
2. data value를 확인, key / dependency 결정: 
   • Multivalued dependencies
   • Functional dependencies
   • Candidate keys (CK)
   • Primary keys (PK)
   • Foreign keys (FK)
3. validity(유효성) / referential integrity constraint(참조 무결성 제약조건) 평가.

 

Count Row

SQL 내장함수 count(*) 사용.

select count(*) from A;

 

Examine Column

SQL 내장함수 Top{Number of Rows} 사용.

select top 5 * from A;

 

Check referential integrity constraint

referential integrity constraint (참조 무결성 제약) :

FK(Foreign Key)의 값은 Null or 참조하는 relation(테이블)의 PK값과 동일.

Subquery(서브쿼리)를 이용해 참조 테이블의 PK값과 다른 값이 있는 지 조사.

select Data_A from Table_A
where Data_A not in
(select Table_A.Data_A from Table_A, Table_B
 where Table_A.Data_A = Table_B.Data_B);

-- Table A의 Data A는 FK.
-- Table B의 PK인 Data B를 reference함.

 

Designing Updateable DB

DB Type

• Updateable이면 보통 BCNF table 씀.
• Read-Only면 보통 BCNF 안씀.

 

Designing Updateable DB

• Updateable DB는 주로 회사의 운영(operational) DB로 사용. 예를 들면 OLTP system(Online Transaction processing system).
• Updateable DB 설계할 땐, 이상이 있는 data나 변경 가능성이 있는 data들 modify(수정)할 것을 생각해야 함.
• 또, 정규화(normalization) 원칙도 생각하면서 설계하셈.

 

Normalization

Advantages / Disadvantages

장점

• 이상 현상(Anomaly) 없앨 수 있음.
• data 중복 줄일 수 있음.
• table 1개 쿼리하는 속도는 빨라짐.

단점

• 복잡해짐. subquery랑 join 복잡하게 많이 써야 됨.
• 그래서 subquery랑 join 많이 써서 쿼리속도 느려짐.

 

Copying Data to New tables

데이터 새로운 table에 복사할때 insert문 쓰삼 (정규화해서 새로운 table 만들 때 쓰라고 써놓은 듯)

insert into Copy_Table
    select data1, data2, data3
    from Original_Table;

 

Choosing not to use BCNF

• BCNF는 보통 anomaly(이상 현상)을 functional dependency(함수 종속)로 해결함.
• BCNF가 적절하지 않을 때도 있음.
• 예를 들면 ZIP code 같은 경우 :
  • ZIP code는 거의 변경할 일이 없음(update가 적다!)
  • ZIP code에서의 모든 anomaly는 보통 하던 대로(normal business practice) 해결할 수 있음.
  • join문 안 쓰는 걸로 속도 빠르게 할 수 있음.

 

Multivalued Dependencies

• multivalued dependency(다치 종속)에서 생기는 anomaly는 문제가 많음(빡셈).
• multivalued dependency(다치 종속)은 항상 다른 column(열) 에 놓는 게 나음! (4NF로의 정규화)

 

Designing Read-Only Databases

Designing Read-Only Databases

• Read-Only DB는 보통 business intelligence system(BI system)에서 사용함.
• 평가, 분석, 계획 등을 위한 정보 저장 용도로 사용할 때 말하는 거임 ㅇㅇ
• Chapter 2에서 소개한 data warehouse에서도 보통 쓴다고 함. Chapter 2 가서 알아서 보고 오삼
• Read-Only DB는 operational DB(운영 DB)에서 data 뽑아와서 쓰는 nonoperational DB임.
• querying, reporting, data mining 등에 씀.
• update되는 일은 없는데.. 가끔 operational DB에서 data 추가되면 그거 새로 가져와서 추가할 때는 있음.

 

Denormalization

• Read-Only DB면 정규화 별로 쓸모 없음. 속도빠른게 짱임.
• Denormalization(비정규화)는 정규화된 테이블에 있는 data들 join하는거.
• join해갖고 non-normalized table에 넣을거임.

 

Denormalizing the Data

대충 FK랑 PK 비교해서 같은것끼리 join해갖고 넣는거임.

insert into Denormalize_Table
    select data1, data2, data3, data4, data5
    from OriginTable1, OriginTable2, OriginTable3
    where OriginTable1.data1 = OriginTable2.data1
        and OriginTable2.data2 = OriginTable3.data2;

 

Customized Tables

• Read-Only DB는 보통 똑같은 데이터 복사해서 들어있는 거 많음.
• 근데 사실 그거 각각 다 특정 기능에 쓰려고 커스텀해놓은거임 ㅋㅋ

 

Common Design Problems

자주 보이는 문제 4가지 정도 있음.

• The Multivalue, Multicolumn problem
• Inconsistent value
• Missing value
• General-purpose remarks column

 

The Multivalue, Multicolumn Problem

• 이거 한 attribute의 여러 값이 여러 column에 저장돼 있으면(흩뿌려져 있으면) 이 문제임.
• Multivalued dependency(다치 종속)의 다른 형태임.
• 다치 종속때처럼 4NF 정규화 하고, multiple value를 다른 table에 저장하면 됨.

 

Inconsistent value

• 서로 다른 유저나 data source가 아주 약간만! 다른 형태로 같은 data값을 가지면 이 문제임.

Different codings:
• SKU_Description = 'Corn, Large Can'
• SKU_Description = 'Can, Corn, Large'
• SKU_Description = 'Large Can Corn‘
Different spellings:
• Coffee, Cofee, Coffeee

뭐 대충 이런 식으로.

• 이거 보통 PK나 FK에서 문제 생길 때 있음.
• 이거 발견하려면
  • referential integrity (참조 무결성) 확인하시고
  • SQL의 Group By 절 있는거 의심가는 column에 써보면 됨.

select data count(*) as data_count
from table
group by data;

 

Missing Values

• Missing Value, Null Value -> 이거 값 이 없는 거임. 저장된 적 자체가 없는거.

 

NULL Values

NULL value는 참 애매함.

• value가 적절하지 않은 걸 수도 있고,
• value가 적절한데 data를 모르는(unknown)걸 수도 있고,
• value도 적절하고 data도 known인데 입력을 안 한 걸 수도 있음.

 

Checking for NULL Values

NULL 연산자 쓰면 NULL check 가능

select count(*) as QuantityNullCount
from table
where Quantity is NULL;

 

General-Purpose Remarks Column

• 이건 column 이름이 Remark, Comment, Note 같은 걸로 지정됐을 때 문제임.
• 그니까 뭔 말이냐면, column이 ''상세설명'' 같이 겁나 길고 설명으로 가득한 뭐 그런 느낌의 data가 들어가는 놈인거지. 별로 변할 일도 없는 data인거.
• Column은 inconsistently하고(좀 바뀌어야 하고), multiple data item을 저장하는거임 원래 ㅇㅇ