디자인 단계
1) 유저들의 데이터 니즈를 모두 분석한다.
2) 데이터 모델을 고른다.
- 데이터 모델의 개념을 적용하고 유저의 요구사항들을 개념스키마로 넣는다.
- 이때 개념스키마는 데이터에서 수행되는 각종 처리들를 가리키는 기능적 요구사항(fuctional requirement)이다.
3) 추상적인 데이터모델을 구현한다.
- 논리적 디자인(Logical Design): 데이터 베이스 스키마를 결정하고, 관계 스키마를 만든다.
- 물리적 디자인(Physical Design): 데이터베이스의 물리적 레이아웃을 결정한다.
※ 불필요한 중복(Redundancy)과 불완전성(Incompleteness)을 조심해야한다.
ERD(Entity Relationship Model): 개체 관계 모델
데이터들과 그 관계를 사람이 이해할 수 있는 현태로 표현하기 위해 쓰이는 모델. 개념적 모델링에 대표적으로 쓰인다.
- 개체(Entity): 개별적으로 구별될 수 있는 모든 것(object). 속성(attributes)들의 집합이기도 하다. 네모로 표현.
- 애트리뷰트, 속성(attributes): 개체가 갖는 속성. 원으로 표현. relationship set의 특징이 될 수도 있다.
- 개체집합(entity set): 같은 성징(properties)와 같은 타입을 갖는 개체들의 집합
- 관계(Relationship): 개체 타입 간의 관계를 의미한다. 마름모로 표현. 보통 두 개체의 관계(Binary)이지만 두 개 이상의 개체를 가리킬 수도 있다. 마름모로 표현한다.
- 관계집합(relationship set): entity set 안의 2개 이상의 개체들이 가지는 수학적 관계.
예를 들어, 은행의 한 고객에 ID, 이름, 주소, 도시 등의 정보가 있으면 정보는 여러 속성을 말하고 한 고객은 개체 하나이다. 한 계좌에 계좌번호와 금액의 정보가 담겨있으면 이 정보는 속성이고, 그 계좌는 하나의 개체이다. 한 명의 고객이 가진 하나의 계좌 사이의 연결은 '예금자'라는 관계이다. 여기서 여러 고객들의 집합인 '고객'과 여러 계좌들의 집합인 '계좌'는 개체집합이고 '고객'과 '계좌'의 관계는 관계집합이다.
애트리뷰트, 속성(attribute)
- 도메인(Domain): 각 애트리뷰트가 가질 수 있는 집합
- 복합 애트리뷰트 (Composite Attribute): 독립적인 애트리뷰트들이 모셔서 생성된 애트리뷰트. 예를들어, 고객명이라는 애트리뷰트가 있을 때, 이는 성과 이름이라는 각각 독립된 애트리뷰트를 가진다. 주소라는 애트리뷰트 또한 도시, 도로명, 우편번호 같은 여러 독립된 애트리뷰트가 모여 생성된 것이다.
+ 단순 애트리뷰트(Simple attribute): 복합과 달리 더이상 분해할 수 없는 애트리뷰트.
- 다중값 애트리뷰트(Multi-Valued Attribute): 하나의 애트리뷰터가 여러개의 값을 가질 때. 예를 들어, 한 고객이 여러개의 휴대폰을 사용해서 번호가 두개라면 이에 해당한다. 두 개의 원으로 표현한다.
+ 단일값 애트리뷰트(Single-valued Attribute): 다중값과 달리 하나의 값을 갖는 애트리뷰트
- 유도 애트리뷰트 (Derived Attribute): 다른 애트리뷰트가 가지고 있는 값으로부터 계산되어 나오는 애트리뷰트. 예를 들어 고객의 생일이 한 애트리뷰터라면 이로부터 나이를 계산해서 나오는 애트리뷰트가 이에 해당한다. 점선으로 된 원으로 표현한다.
mapping cardinality
: 관계를 맺는 두 개체 타입에서 한 개체가 얼마나 많은 다른 개체와 관련되는지를 나타낸다. 즉. 몇대몇으로 대응하는지.
• One to one: 일대일(1:1)
• One to many: 일대다(1:N)
• Many to one: 다대일(N:!)
• Many to many:다대다(N:N)
역할(role)
: 개체와 관계, 개체와 속성, 관계와 속성을 연결한다. 선으로 표현되며 그 선 위에 역할을 기재할 수 있다.
또한 cardinality를 표현할 수 있는데 하나(one)를 가리킬 때는 화살표 모양으로→, 여러개(many)를 가리킬때는 그냥 직선으로 표현한다.
키(Keys)
: 데이터베이스 안에서 특정 조건을 만족하는 행을 찾거나 순서대로 정렬할 때 다른 행과 구별될 수 있는 기준이 되는 속성의 집합이다. 즉, 무언가를 식별하는고유한 식별자 기능을 한다.
- 슈퍼키(super key): 다른 객체와 중복되지 않고 고유한 값을 가지는 한개 혹은 그 이상의 속성들의 집합. 하나의 키로 특정 행을 바로 찾을 수 있는 고유한 데이터 속성을 가지고 있다면 유일성을 만족하는 것이고, 유일성만 만족한다면 슈퍼키가 될 수 있다. 여러 개체 집합의 기본키를 합쳐서 슈퍼키로 만들 수도 있다.
예를 들어, '예금자'라는 집합 안에 고객명과 계좌번호라는 속성이 있을 때 고객명의 각 속성끼리와 계좌번호의 각 속성들끼리 겹치지 않는다면 각각 슈퍼키가 될 수 있다. 하지만 이름이 중복된 값이라면 고객명은 슈퍼키가 될 수 없다. 이때 '고객명+계좌번호'로 중복이 되지 않게 한다면 이 combination은 슈퍼키가 될 수 있다.
- 후보키(candidate key): 각 행을 유일하게 식별할 수 있는 최소한의 속성들의 집합으로 유일성과 최소성을 동시에 만족해야한다(minimal super key). 즉, combination은 후보키가 될 수 없다. 후보키가 여러가지 있을 오직 하나만이 기본키(primary key)가 될 수 있다.
- 기본키(primary key): 후보키들 중에서 하나를 선택한 키로 최소성과 유일성을 만족한다. 테이블에서 기본키는 오직 1개이며 NULL값과 중복된 값을 가질 수 없다. 애트리뷰트 안에 밑줄을 그어 표시한다.
※ 여러 후보키에서 기본키를 선택할 때 관계집합의 의미를 잘 생각해서 골라야한다.
※ 무엇이 후보키인지 결정할 때 mapping cardinality를 반드시 생각해야한다.
참여 제약조건(Participation Constraint)
: 관계를 맺는 두 개체 타입에서 한 개체가 다른 개체에 의존하는지를 나타내는 제약조건이다.
- 전체 참여(total participation): 적어도 하나의 관계에서 그 관계집합에 있는 개체의 모든 개체들이 참여하는 것을 가리킨다. 이중선으로 표현한다.
- 부분 참여(partical participation): 몇몇 개체만 참여하고 몇몇은 참여하지 않을 수도 있다. 실선으로 표현한다.
※ binary 관계 표현시 주의사항: binary가 아닌 관계더라도 binary 관계로 표현하는 것이 더 좋을 때가 있기도 한다. 예를 들어, '아이'와 '어머니', '아버지'의 세가지 개체는 ternary 관계이지만 아이와 '어머니, 아버지'로 묶어서 binary로 대체한다. 이 경우 오직 어머니만 있거나 없는 경우 등의 부분 참여를 허용하기 때문에 더욱 편하다.
아래처럼 ternary 관계에서 애트리뷰트 E를 추가하여 관계집합 R로 각 개체 A, B, C를 연결해주면 none-banary가 banary 형태로 변환된다.
하지만 모든 것을 변환할 수 있는 것은 아니며 불가능한 것도 존재한다.
여기서 E를 식별 가능한 개체가 아닌 약한 개체(Weak attribute)로 만들어주면서 제약조건을 피할 수 있다.
- 약한 개체(Weak attribute): 자신의 기본키가 없는 개체타입. 두개의 네모로 표현한다. 또한 약한 개체는 항상 의존적이기 때문에 제약조건은 전체 참여이다. 약한 개체 집합의 부분키는 강한 개체 집합의 기본키와 연결되어야한다.
- 부분키(partial key) or 구별자(discriminator): 약한 개체를 유일하게 식별할 수있는 최소개의 속성으로 구성된다. 약한 개체의 점선 밑줄로 표현한다.
※ 약한 개체 집합이 의존하는 강한 개체 집합의 기본키와 약한 개체 집합의 구별자가 더해진 것이 약한 개체의 기본키이다.
- 식별 개체 집합(identifying entity set): 다른 개체의 존재 여부와 상관 없이 존재할 수 있고 기본키가 있는 개체. 두개의 다이아몬드로 표현한다. 약한 개체 집합과 One to Many 관계로 이루어져 있다.
'Programing > [DB]SQL' 카테고리의 다른 글
[DB] E-R 모델을 이용한 데이터베이스 디자인(2), UML (0) | 2020.10.11 |
---|---|
[DB]데이터베이스 개념(3) - DBA, DC Manager, 클라이언트/서버, 분산처리 (0) | 2020.09.14 |
[DB] 데이터베이스 개념(2) - 독립성, 구조, 매핑, DBA 등 (0) | 2020.09.13 |
[DB] 데이터베이스 개념(1) - DBMS와 구성요소, 데이터 모델 (0) | 2020.09.12 |