3. Database Design
Database
한가지 이상의 목적을 위해 정리된 데이터의 집합.
그렇지만 대개 디지털 형태로 저장된 데이터를 말함.
운영(operational) 데이터베이스
대개 OLTP(Online Transaction processing) 시나리오
분석(analytical) 데이터베이스
대개 OLAP(Online Analytical processing) 시나리오
4. Database Design
Early Database Models
계층형 (hierachical) 데이터 베이스
inverted tree 형태
부모/자식의 관계, 하나의 부모
8. Database Design
Objectives of Good Design
튼튼한 데이터베이스 구조를 설계하는데 필요한 기술 제공
데이터 처리 문제의 대부분은 중복(redundant), 이중(duplicate),
잘못된 데이터, 필요한 데이터의 누락 등에 기인한다. 이러한 문제
는 잘못된 정보를 생성하고, query와 report 작성을 어렵게 한다.
좋은 설계 방법론 채택 시 이런 문제의 대부분을 방지 할 수 있다.
설계 작업을 단계적으로 안내할 기술의 조직화된 집합을 제공
기술의 조직화는 설계의 모든 단계에서 정보에 근거한 판단을 할
수 있게 해 준다.
실수와 설계 반복을 최소화하도록 도와준다.
데이터베이스 설계시 실수를 하게 되지만, 좋은 방법론은 설계에서
의 오류를 인식하도록 도와주고 그것을 수정할 수 있는 도구를 제공
한다. 추가적으로, 방법론 내에서의 기술의 조직화는 주어진 설계
작업을 불필요하게 반복하는 것을 방지해 준다.
9. Database Design
Objectives of Good Design
설계 작업을 쉽게 해 주고 데이터베이스를 설계하는데 소비되는
시간을 줄여준다.
설계에 임의의 시행착오적인 접근법을 사용하면 좋은 방법론이
제공하는 논리와 조직화가 결여되어 있기 때문에, 틀림없이 귀
중한 시간을 낭비하게 된다.
RDBMS 소프트웨어를 더 완전하고 효율적으로 이해하고 사용하
도록 도와준다.
적절한 설계에 대한 지식이 확장되고 자라면서 주어진 RDBMS
가 특정 도구들을 제공하는 이유와 RDBMS 프로그램 내에서 구
조를 구현하는데 이 도구들을 어떻게 사용할지를 실제로 이해하
기 시작한다.
10. Database Design
Objectives of Good Design
데이터베이스는 필수적인(required)것과 임의적인(ad hoc) 정보
추출을 둘 다 지원한다.
데이터베이스는 설계 과정에서 정의한 정보 요규 사항 뿐만 아
니라 사용자에 의해 제기될 수 있는 임의의 질의를 지원하는데
필요한 데이터를 반드시 저장해야 한다.
테이블은 적절하고 효율적으로 구성되어야 한다.
데이터베이스의 각 테이블은 단일 주제를 표현하고 비교적 독특
한 필드들로 구성되며 중복 데이터를 절대적으로 최소화하고 유
일한 값들을 가진 필드에 의해 데이터 베이스 내에서 식별된다.
필드, 테이블 및 관계 수준에서 데이터 무결성이 부과된다.
이 무결성 수준들은 데이터 구조와 그것의 값이 항상 유효하고
정확하다는 것을 보장하는데 도움을 준다.
11. Database Design
Objectives of Good Design
데이터베이스는 조직과 관련된 업무 규칙을 지원한다.
데이터는 사업에 향상 의미가 있는 유효하고 정확한 정보를 반
드시 제공해야 한다.
데이터베이스는 장래의 성장에 적합하다.
데이터베이스 구조는 사업의 정보 요구가 변경되고 성장함에 따
라 쉽게 수정하고 확장할 수 있어야만 한다.
12. Database Design
Benefits of Good Design
데이터베이스 구조를 쉽게 수정하고 유지할 수 있다.
필드나 테이블에 대한 수정이 데이터베이스의 다른 필드나 테이
블에 악영향을 미치지 않는다.
데이터를 쉽게 수정할 수 있다.
테이블의 주어진 필드의 값을 수정하는 것이 테이블 내의 다른
필드들의 값에 악영향을 미치지 않는다. 더군다나 잘 설계된 데
이터베이스는 이중 필드들을 절대적으로 최소화한다. 따라서 전
형적으로 한 필드에서 만 특정 데이터 값을 수정한다.
정보를 추출하기 쉽다
테이블들이 잘 구성되어 있고 그들 사이의 관계가 적절하게 설
정되어 있으므로, 쉽게 질의를 만들 수 있다.
13. Database Design
Benefits of Good Design
최종 사용자 애플리케이션이 쉽게 개발 및 구축된다.
잘못 설계된 데이터베이스로 작업할 때 발생하는 피할 수 없는
문제들을 여기저기서 해결하는 대신, 프로그래밍과 데이터 조작
작업을 다루는데 더 많은 시간을 쓸 수 있다.
15. Database Design
Value-Related Terms
데이터(Data)
데이터베이스에 저장하는 값이 데이터다. 데이터는 어떤 수동적
이거나 자동적인 처리에 의해 바뀌기 전까지는 같은 상태를 유
지한다는 측면에서 정적이다.
표면적으로 데이터들은 의미가 없다.
Figure 3.1 An example of basic data.
George Edleman 92883 05/16/96 95.00
16. Database Design
Value-Related Terms
정보(Information)
정보는 작업을 하거나 찾아 볼 때 의미 있고 유용하도록 처리한
데이터다. 이것은 데이터베이스에 저장된 데이터에 비교할 때,
끊임없이 변한다는 점에서, 그리고 무한대의 방법으로 처리되고
표현할 수 있다는 점에서 동적이다. 정보는 SELECT문의 결과
를 컴퓨터 화면 상에서 폼으로 표시하거나, 종이에 인쇄하여 보
여줄 수 있다. 기억해야 할 점은 데이터를 어떠한 방법으로 처리
해서, 그것을 의미 있는 정보로 바꿀 수 있도록 해야 한다는 것
이다.
18. Database Design
Value-Related Terms
널(null)
널은 누락되었거나 미지의 값을 나타낸다. 널은 0이나 하나 이상
의 공백 문자열이 아니다.
• 0은 매우 다양한 의미를 가진다. 0개, 0원, error no 등등
• 하나 이상의 공백으로 구성된 텍스트 문자열은 SQL과 같은
질의어에게 의미가 있다.
• 길이가 0인 문자열도 SQL에서 허용되는 값이고, 상황에 따라
의미도 있다.
19. Database Design
Value-Related Terms
널 값
널값은 적용하지 않은것(does not apply)과 적용할 수 없는 것
(is not applicable)이 있는데 적용할 수 없는 것을 나타내기 위
해서 ‘N/A’, ‘적용할 수 없음(Not Applicable)’과 같이 실제 값을
넣어 구분하는 것이 정보를 좀 더 명확하게 만든다.
널 관련 문제점
(Null * 3) + 4 = Null
(25 * 3) + Null = Null
널은 수식의 계산에 영향을 미친다.
20. Database Design
Structure-Related Terms
테이블(Table)
관계형 모델에 따르면 관계형 데이터베이스의 데이터는 사용자
가 테이블이라고 여기는 릴레이션에 저장된다.
각각의 릴레이션은 투플(레코드)과 속성(필드)들로 구성된다.
21. Database Design
Structure-Related Terms
데이터 테이블(Data Table)
일반적으로 사용하는 테이블, 정보 제공용 데이터를 저장하는
테이블, 조작(갱신, 삭제 등)이 가능하고, 특정한 형식의 정보로
처리가 가능, 동적인 테이블
검증테이블(Validation Table, also known as lookup table)
데이터 무결성을 구현하기 위해 사용되는 데이터를 저장, 도시
이름, 카테고리, 제품 코드등을 나타냄, 변경이 드물어 정적이라
할 수 있음
22. Database Design
Structure-Related Terms
필드(Field)
필드는 데이터베이스에서 가장 작은 구조이고, 속해 있는 테이
블의 특성이 된다. 관계형 데이터베이스 이론에서는 속성
(attribute)라고 부름.
필드에 속한 데이터는 추출해서 사용자가 원하는 대부분의 정
보 형태로 표현이 가능하다.
적절하게 설계된 데이터베이스의 모든 필드는 오직 하나의 값
만 포함하고, 그 이름은 그것이 가지는 값의 종류를 식별한다. 이
렇게 하면 삽입, 수정, 정렬등의 작업을 할때에 효과적이다.
23. Database Design
Structure-Related Terms
잘못 디자인한 데이터베이스의 필드
1. multipart (composite) field, 2개 다른 값들이 포함된 필드
2. multivalued field, 같은 타입의 값들을 여러 개 포함
3. calculated field, 텍스트를 합치거나 수식에 의한 결과
24. Database Design
Structure-Related Terms
레코드(recode)
레코드(투플)는 테이블 항목의 unique한 인스턴스를 나타낸다.
테이블 내의 전체 필드 셋으로 구성되고, 값을 포함하지 않은 필
드의 존재 유무는 상관이 없다.
25. Database Design
Structure-Related Terms
뷰(View)
뷰는 하나 이상의 테이블로 구성된 가상(virtual) 테이블이다. 뷰
를 구성하는 테이블들을 base table이라고 부르기도 한다.
뷰의 장점
1. 동시에 여러 테이블의 데이터를 이용할 수 있게 해준다.(각
테이블 간에 연결, 관계가 있을때)
2. 사용자가 테이블(테이블 그룹)의 특정 필드를 보거나 조작하
는 것을 막을 수 있다. 보안상 유리
3. 데이터 무결성을 지키게 해준다. (validation view)
27. Database Design
Structure-Related Terms
키(Key)
키는 테이블 내에서 특정 역할을 하는 특별한 필드다.
많은 키가 있지만 중요한 두 가지 키는 주 키(primary key)와 외
래 키 (foreign key)가 있다.
• 주 키 값은 전체 데이터베이스에서 특정 레코드를 식별한다.
• 주 키 필드는 전체 데이트베이스에서 주어진 테이블을 식별
한다.
• 주 키는 테이블 수준의 무결성을 강화하고, 데이터베이스 내
의 다른 테이블과의 관계 설정을 도와준다.
데이터베이스의 각 테이블은 반드시 주 키를 가져야만 한다.
30. Database Design
Relationship-Related Terms
관계(Relationship)
두 개 테이블이 있을 때, 어떤 방법으로 첫 번째 테이블의 레코
드와 두 번째 테이블의 레코드를 연관지을 수 있다면, 두 테이블
은 관계가 있다. 관계는 주키와 외래키의 셋을 통해 형성하거나
보통 링킹테이블 혹은 연관 테이블(linking table or associative
table)이라고 부르는 제삼의 테이블을 이용해 관계를 형성할 수
있다.
• 멀티 테이블 뷰를 만들 수 있게 해준다.
• 불필요한 데이터를 줄이고, 중복 데이터를 제거하는데 도움
을 주기 때문에, 데이터 무결성을 지키는데 매우 중요하다.
36. Database Design
Relationship-Related Terms
참여의 종류(Type of Participation)
테이블의 관계 참여 여부는 mandatory이거나 optional일 수 있
다.
관계에 참여하는 TABLE_A와 TABLE_B가 있다고 할 때
• TABLE_B에 레코드를 입력하기 전에, TABLE_A에 적어도
한 개의 레코드를 넣어야 하는 경우라면 TABLE_A의 참여는
mandatory이다.
• TABLE_B에 레코드를 넣기 위해서 TABLE_A에 필수적으로
넣어야 할 레코드가 없다면 TABLE_A의 참여는 optional이
다.
38. Database Design
Relationship-Related Terms
참여 수준(Degree of Participation)
참여의 수준은 연관된 테이블의 단일 레코드와 반드시 연결되어
야 하는 주어진 테이블의 최소 레코드 개수와, 연관된 테이블의
단일 레코드와 연결될 수 있도록 허용되는 주어진 테이블의 최
대 레코드 개수를 결정한다.
39. Database Design
Integrity-Related Terms
필드명세(Field Specification)
필드명세(전통적으로 도메인이라 부름)은 필드의 모든 요소를
나타낸다. 각 필드 명세는 일반적(general), 물리적(physical),
논리적(logical) 요소의 세가지 요소를 가진다.
• 일반적 요소는 필드의 가장 기초적인 정보를 구성하며, 필드
이름, 설명, 그리고 부모테이블과 같은 항목들을 포함한다.
• 물리적 요소는 필드가 어떻게 만들어지고, 그것을 사용하는
사람에게 어떻게 표현될지를 결정한다. 이 범주는 데이터 형,
길이, 그리고 표시형식과 같은 항목들을 포함한다.
• 논리적 요소는 필드에 저장되는 값을 설명하며, 필수 값, 값의
범위, 기본값과 같은 항목들을 포함한다.
40. Database Design
Integrity-Related Terms
데이터 무결성(Data Integrity)
데이터 무결성은 데이터베이스 내 데이터의 유효성(validity), 일관
성(consistency), 정확성(accuracy)를 가르킨다.
• Table-level integrity(entity integrity)
테이블 내에 중복된 레코드들이 없고, 테이블 내에서 각 레코드를
식별하는 필드가 유일하고 널이 아니라는 것을 보장한다.
• Field-level integrity(domain integrity)
각 필드의 구조가 정확하고, 각 필드의 값이 유효하고 일관성 있고
정확하며, 같은 종류의 필드들은 데이터베이스 전체에 걸쳐 일관성
있게 정의되어 있는 것을 보장한다.
• Relationship-level integrity(referential integrity)
테이블 쌍 사이의 관계가 정확하고, 테이블들의 레코드들이 임의의
테이블에서 삽입,갱신,삭제 될 때마다 동기화 되는 것을 보장한다.
• 업무규칙
조직이 데이터를 인식하고 사용하는 방법을 기초로 하여, 데이터베
이스의 특정한 측면에 대해 제약 또는 규제를 부과한다.
42. Database Design
Type of Table
데이터 테이블(Data Table)
데이터베이스가 제공하는 정보의 근간이며 정보 구성에 중요한
역할을 맡는 테이블이다.
링킹테이블(Linking Table)
두 개의 테이블이 다대다 관계를 가질 수 있게 연결 해주는 테이
블
부분테이블(Subset Table)
특별한 데이터 테이블과 관련 있는 필드들을 포함하고, 세부적
인 항목에서 사용하기 위해 정의한다.
검증테이블(Validation Table)
비교적 정적인 데이터를 포함하고, 데이터 무결성을 위해 중요
하다.
43. Database Design
Refining the Table Names
Guidelines for Creating Table Names
Unique하고 descriptive한, 전체 구성에 의미가 있는 이름
정확하고, 명확하고 모호하지 않은 이름
의미 전달이 가능하면서 되도록 짧은 이름
물리적 특징을 나타내는 단어 사용 금지(파일, 코드, 테이블 등)
두음 문자(acronym), 약어(abbreviation) 사용 금지
과도하게 영역을 제한하는 이름 사용 금지
하나 이상의 주제를 이름 사용금지 (and, or, , &, 기타)
이름의 복수형
44. Database Design
Refining the Table Names
Guidelines for Composing a Table Description
테이블을 정확하게 정의하는 문장을 포함
테이블이 전체구조(organization)에서 어떤 중요한 역할을 담당
하는지 설명
명확하고 간결한 설명을 작성
구현정보는 포함하지 않음
다른 테이블의 설명에 의존적인 설명은 작성하지 않음(뭐는 어
디 참조)
테이블 설명에 예를 사용하지 않음
45. Database Design
Refining the Fields
Improving the Field Names
Unique하고 descriptive한, 전체 구성에 의미가 있는 이름
정확하고, 명확하고 모호하지 않은 이름
의미 전달이 가능하면서 되도록 짧은 이름
두음 문자(acronym), 약어(abbreviation) 사용 금지
헷갈릴 수 있는 단어는 사용하지 않음
하나 이상의 주제를 이름 사용금지 (and, or, , &, 기타)
이름의 단수형
46. Database Design
Refining the Fields
Using an Ideal Field to Resolve Anomalies
테이블 항목의 고유한(구별되는) 특성을 나타냄
단지 한 개의 값만 포함
더 작은 요소로 나눌 수 없음
계산된 값을 포함하지 않음
전체 데이스베이스 내에서 유일
50. Database Design
Candidate Keys
테이블을 위해 설정하는 첫 번째 종류의 키는 후보 키인데, 이것
은 테이블 항목의 단일 인스턴스를 유일하게 식별해 주는 하나
의 필드 또는 필드 집합이다. 각 테이블은 적어도 하나의 후보
키를 가져야만 한다. 궁극적으로 테이블의 사용가능한 후보키들
의 풀(pool)을 검사하고 그 중 하나를 테이블의 공식적인 주 키
로 지정한다.
51. Database Design
Candidate Keys
Elements of a Candidate Key
multipart 필드는 안됨
unique value
null을 포함하지 않음
보안, 개인적인 것은 안됨 (예 : 주민등록번호)
optional한 값이 아님(전체든 부분이든)
unique한 값을 나타내기 위해 필요한 최소한의 필드로 구성
값들은 유일하고 배타적으로 테이블 내 레코드를 식별
수정은 거의 이루어지지 않음(아주 아주 드물게)
52. Database Design
Primary Keys
주 키 필드는 데이터베이스 전체에 걸쳐 테이블을 배타적으로
식별하고, 다른 테이블들과의 관계를 설정하는 것을 도와준다.
주 키 값은 테이블 내의 주어진 레코드를 유일하게 식별하고, 전
체 데이터베이스에 걸쳐 이 레코드를 배타적으로 나타낸다.
53. Database Design
Primary Keys
Rules for Establishing a Primary Key
각 테이블은 단지 하나의 주 키를 가져야만 한다
데이터베이스 내의 각각의 주 키는 반드시 유일해야만 한다.
54. Database Design
Alternate Keys / Non-Keys
Alternate Keys
Candidate Key중 Primary Key를 대체해서 사용할 수 있는 키
(예: 이름, 아이디 등)
Non-Keys
Candidate Key중 Primary Key도 Alternate Key도 아닌 키,
별로 중요하지 않다.
59. Database Design
Quiz
1. 잘못 설계된 Database의 예입니다. 개선하세요.
2. 10M명 회원, 100k명 동시접속자, 10k명 신규회원이 유지되
는 시스템의 DB 설계가 필요합니다. 가입 시에 이름, 아이디, 비
밀번호, 사진(1MB), 국가, 도시, 언어를 입력 받아 저장합니다.
세션은 로그인 한 시간으로 부터 갱신되지 않으면, 30초 후
expired 됩니다. 세션 역시 DB에 저장합니다. 로그인 시 해당
사용자의 국가와 도시, 언어를 보여줍니다.
DB는 blob 데이터형을 지원하지 않으며, 파일시스템은, 한 디렉
토리 내의 파일이 11k개를 넘어서면 속도가 현저하게 느려집니
다.
DB를 설계하고, 그렇게 설계한 이유와 예상 성능을 설명하세요.
