Denormalization for Performance
May want to use non-normalized schema for performance
For example, displaying prereqs along with course_id and title requires join of course with prereq
Alternative 1: Use denormalized relation containing attributes of course as well as prereq with all above attributes
faster lookup
extra space and extra execution time for updates
extra coding work for programmer and possibility of error in extra code
Alternative 2: use a materialized view defined as
course (inner join) prereq
Benefits and drawbacks same as above, except no extra coding work for programmer and avoids possible errors
course : 과목, prereq : 선수 과목
퍼포먼스를 위해 정규화하지 않음
방법 1: 정규화를 하지 않고 하나의 테이블에 때려놓을 경우
빠르게 확인 가능?
용량이 많아짐(카티전 프로덕트로 인한 중복)
업데이트(삽입, 수정) 시행 시간이 길어진다. (삽입 이상)
프로그래머에게 추가적인 코딩이 요구되며, 코드에서 에러가 생길 확률이 증가한다.
(중복된 데이터 처리가 필요하기 때문에)
방법 2: 분해 해놓지만, 뷰를 이용해 조인을 시켜놓는다.
따라서 추가적으로 뷰를 사용하는 형태.
faster lookup
extra space(memory도 space), extra execution time for updates(view도 추가적인 업데이트)
추가적인 코딩 작업은 필요없다.
일반적으로 방법2가 좋다.
선수과목이 3개일 경우? 그냥 컬럼 3개 만들면 된다. 진짜 많은 many 형태일 경우 나누는게 좋다?
Other Design Issues
Some aspects of database design are not caught by normalization
Examples of bad database design, to be avoided:
Instead of earnings (company_id, year, amount ), if we use
Multiple relations, earnings_2004, earnings_2005, earnings_2006, etc., all on the schema (company_id, earnings).
Above are in BCNF, but make querying across years difficult and needs new table each year
company_year (company_id, earnings_2004, earnings_2005,
earnings_2006)
Also in BCNF, but also makes querying across years difficult and requires new attribute each year.
Used in spreadsheets, and in data analysis tools
db 디자인 몇몇 특징은 정규화로 인해 발현되지 않을 수 있다.
피해야되는 db 디자인 예제:
연도 컬럼을 만드는 대신 연도별 릴레이션을 만드는 경우 시계열 분석 할 때 어렵게 만든다.
또는, 연도별로 따른 컬럼으로 관리 시 조인등을 할 때 문제가 생긴다?
