목차
-
▼ Why ? What ?
-
▼ Database Modeling (Design Phases)
-
▼ E-R Model
-
E-R Model (Entity Relationship Model)
-
Entity Sets
-
▼ ERD
-
Entity Relationship Diagram
-
Entity sets
-
Relationship Sets
-
Roles
-
Relationship Set의 차수(Degree)
-
Attributes
-
Mapping Cardinality(관계 차수) Constraints
-
Weak Entity Sets (중요)
-
Extended E-R Features
-
E-R 설계시 고려해야 할 사항
-
Summary of Sysmbols used in E-R Notation
-
▼ UML
-
UML (Unified Modeling Language)
▼ Why ? What ?
이번 주 "Database" 강의에서 DB 모델링(Modeling)에 필요한 과정, 그리고 'E-R Model' 에 대해서 배웠고 이러한 E-R Model을 다이어그램(Diagram)으로 어떻게 작성(ERD)하는지에 대해 배웠다. 앞서 말한 개념들은 전부터 공부하려고 했던 파트들이었는데 계속 미루다보니.. 이번 기회에 기말 시험도 대비할 겸 강의 내용을 복습하면서 정리해보려고 한다.
▼ Database Modeling (Design Phases)
데이터베이스 모델링 ?
- 간단히 말해서, 데이터베이스 스키마 설계 프로세스라고 할 수 있다.
Initial phase
- 잠재적(prospective) 사용자가 필요로 할 데이터, 즉 요구사항을 충분히 고려한다.
Second phase
- 개념적 데이터 모델을 선택 !
- 요구사항을 데이터베이스의 개념적 스키마(conceptual scheam)로 변환시킨다.
➜ 그렇게 도출된 개념적 스키마는 기능적 요구사항을 나타낸다.
( 데이터에 대한 연산 혹은 트랜잭션을 표현. )
- 요구사항을 데이터베이스의 개념적 스키마(conceptual scheam)로 변환시킨다.
Final phase
- 그렇게 생성된 추상적인 데이터 모델을 구체화시킨다.
- Logical design
: 데이터베이스 스키마(schema)를 결정한다.
➜ 개념적 스키마를 논리적 스키마에 대응시킨다.
➜ 주어진 상황에 있어서 스키마에 적합한 집합이 무엇일지 생각 !
ex) 사업과 관련된 것이라면, 데이터베이스에 기록해야 할 'attributes' 가 무엇일지?
컴퓨터 과학과 관련된 것이라면, 무슨 관계형 스키마를 설계해야 하며 다양항 스키마들 속에서 'attributes' 을 어떻게 분배해야 할지? - Physical design
: 논리 데이터 모델이 데이터 저장소로서 어떻게 컴퓨터 하드웨어에 표현될 것인가를 결정한다.
- Logical design
- 데이터베이스 스키마를 설계할 때에 주의해야 할 점
- Redundancy : 데이터들의 중복으로 인해 데이터들의 일관성을 유지하기 힘들어질 수 있다.
- Incompleteness : 설계가 잘못되면 기업의 특정 부분을 모델링하기 어려워질 수 있다.
- Redundancy : 데이터들의 중복으로 인해 데이터들의 일관성을 유지하기 힘들어질 수 있다.
▼ E-R Model
E-R Model (Entity Relationship Model)
- 'Entities' 와 'Relationships' 의 집합.
- Entity
: 다른 오브젝트로부터 구별될 수 있는 오브젝트를 말한다.
➜ 'Attributes' 의 집합. - Relationship
: 'Entity' 들 간의 관계를 의미한다.
- Entity
- E-R Model은 크게 다음 세 가지로 구성되어 있다.
- 엔티티 집합(Entity sets)
- 관계 집합(Relationship sets)
- 속성(Attributes0
- ER model은 데이터베이스의 전체적인 logical structure를 ER diagram이라는 직관적인 형태로 표현 가능하다 !
Entity Sets
- 같은 타입, 즉 같은 속성(properties)를 공유하는 엔티티(entity)들의 집합이다.
- instructor = (ID, name, salary)
- course = (course_id, title, credits)
- 'Attributes' 의 하위 집합(name, salary, etc.)은 'entity sets' 의 기본키(primary key)를 형성한다.
➜ 즉, 하위 집합의 각각의 요소들은 고유하게 식별 가능하다.
ex) 이름이 같거나 월급이 같더라도 누가 어떤 사람인지 구별 가능하다.
▼ ERD
Entity Relationship Diagram
- 읽히는 그대로 'Entity' 와 'Relationship' 에 중점을 두는 데이터베이스 구조(structure)를 직관적으로 볼 수 있게 그려놓는 '다이어그램(Diagram)' 이다.
Entity sets
- 사각형(rectangle)으로 표현하며, Primary key attributes는 밑줄(underline)을 쳐서 표현한다.
Relationship Sets
- 줄(line)을 그어 엔티티들 간의 관계를 표현한다.
- 단, 엔티티와 엔티티가 직접 연결되는 것이 아니라 엔티티들 사이에 연관된 또다른 속성(attribute) 데이터가 있을 수 있다.
- 아래에서 다이아몬드로 그린 <Enrolled in>가 엔티티 타입(type)인 'Student'와 'Course' 사이에 존재하는 '관계의 타입(Relations type)' 이다.
- 'Attributes' 와 함께 'Relationship sets' 을 그리면 다음과 같다.
Roles
- 'Relationship set', 즉 관계에 대한 설명이 필요할 때 유용하다.
Relationship Set의 차수(Degree)
- Binary relationship
➜ 두 개의 'entity set' 을 포함. - 세 개 이상의 'entity sets' 를 포함하는 'relationship' 은 드물다.
- Non-binary relationship sets
➜ 세 개의 관계(ternary relationship)으로 이루어지는 E-R Diagram을 말한다.
Attributes
- Single-valued attribute
: 단 하나의 값으로 구성된 'attribute'. - Multivalued attribute
: 두 개 이상의 값으로 구성된 'attribute'.
- Derived attribute
: 또다른 'attribute' 로부터 파생된 'attribute'.
- Domain
: 각각의 'attribute' 에 해당되는 값들의 집합. - Attribute
: Entity 타입을 정의하는 속성(property)라고 할 수 있다.
- Key attribute
: Entity set에서 각각의 'entity' 를 고유하게 식별해주는 'attribute' 를 말한다.
➜ 밑줄을 쳐서 표현한다. (underlying lines)
- Composite attribute
: 다른 'attribute' 들로 구성된 'attribute'.
Mapping Cardinality(관계 차수) Constraints
- Cardinality constraints
: 'Relationship' 이 존재하는 두 entity 사이에 한 entitiy에서 몇개의 다른 entity와 대응되는지 나타내는 제약조건이다.
- One to One
One: "instructor" ➜ "student" 와 relationship <advisor>를 통한 관계가 많아도 하나이어야 한다.
One: "student" ➜ student와 마찬가지이다.
- One to Many
Many: "instructor" ➜ "student" 와 relationship <advisor>를 통한 관계가 0개 이상이어야 한다.
One: "student" ➜ "instructor" 와 relationship <advisor>를 통한 관계는 많아도 하나이어야 한다.
- Many to one
One: "instructor" ➜ "student" 와 relationship <advisor>를 통한 관계는 많아도 하나이어야 한다.
Many: "student" ➜ "istructor" 와 relationship <advisor>를 통한 관계가 0개 이상이어야 한다.
- Many to many
Many: "instructor" ➜ "student" 와 relationship <advisor>를 통한 관계가 0개 이상이어야 한다.
Many: "student" ➜ "istructor" 와 relationship <advisor>를 통한 관계가 0개 이상이어야 한다.
( 하지만, 엔티티 간의 관계가 둘다 0개일 경우는 드물다. )
- Total participation (2개의 선으로 표현)
: Entity set에 속해있는 모든 'entity' 는 'relationship set' 과 적어도 하나의 'relationship' 에 참여하고 있어야 한다.
➜ 아래 다이어그램의 경우, 모든 "student" 는 "instructor" 와 적어도 하나의 'relationship' 을 갖고 있다.
- Partitial participation
: 모든 엔티티들이 'relationship' 에 참여할 필요는 없다.
➜ 위의 다이어그램을 예로 들면, <adviser>의 'relationship' 에 대한 "instructor" 의 참여는 부분적이다.
- A minimum value of 1 ➜ "Total participation"
A maximum value of 1 ➜ 많아도 하나의 'relationship' 에 참여.
A maximum value of * ➜ 제한이 없다. (no limit)
아래의 다이어그램을 분석해보면,
"instructor" 는 0 이상의 학생을 <advise> 할 수 있고,
각 "student" 는 단 한 명의 <advisor> 만 가질 수 있다.
Weak Entity Sets (중요)
- 'Weak entity' 의 존재(existence)를 보장하기 위해서 'weak entity' 는 'strong entity' 에 의존한다.
- 'Weak entity set' 과 연결되는 'relationship set' 은 double diamond로 표현된다.
- 'Weak entity set' 의 Primary key는 여러 개일 수 있다.
( Not single primary key )
Extended E-R Features
- 사실 데이터의 복잡도가 증가할수록 기존의 (traditional) ER Model은 데이터베이스 모델링이 힘들다.
➜ 추가된 몇가지 새로운 개념(concepts)
- Specialization (특수화)
- Generalization (일반화)
- Aggregation (집단화)
- Specialization (특수화)
- Specialization (⭤ Genralization)
- "Top-down" 접근
➜ lower-level entity set은 연결된 higer-level entity set의 모든 'attribute' 와 'relationship' 을 상속하고, 몇 개의 'attribute' 를 추가하는 방식이다.
- Generalization (⭤ Specialization)
- "Bottom-up"
➜ 여러 entity sets 사이에서 공통되는 'attribute' 를 찾고, 공통된 'attribute' 만으로 구성된 'entity set' 을 생성하는 방식이다.
➜ 즉, lower-level entity를 먼저 생성하고 higer-lever entity를 생성하는 것이다.
- Aggregation
: 여러 개의 entity들 사이의 'relation' 이 단일 entity처럼 다뤄지는 방식이다.
E-R 설계시 고려해야 할 사항
- 오브젝트를 상징하는 attribute 또는 entity set 사용.
- 'strong entity set' 혹은 'weak entity set' 사용.
- 'binary relationship' 과 'ternary relationship' 중 무엇을 채택할지.
- Specializaiton, Generalization
➜ 설계에 대한 모듈성(modularity) 고려. - Aggregation
➜ 내부적인 구조에 대한 세부사항(details)를 신경쓰지 않고 집약된 entity를 단일 유닛(unit)처럼 다룰 수 있다.
Summary of Sysmbols used in E-R Notation
▼ UML
UML (Unified Modeling Language)
- 모델을 만드는 표준 언어이다.
- UML이 사용되는 경우
- 다른 사람들과의 의사소통 또는 설계 논의
- 전체 시스템의 구조 및 클래스의 의존성 파악
- 유지보수를 위한 설계의 back-end 문서
- 다른 사람들과의 의사소통 또는 설계 논의
- UML Class Diagram은 E-R Diagram과 일치하지만, 몇 가지 다른 점이 있긴 하다.
▼ Why ? What ?
이번 주 "Database" 강의에서 DB 모델링(Modeling)에 필요한 과정, 그리고 'E-R Model' 에 대해서 배웠고 이러한 E-R Model을 다이어그램(Diagram)으로 어떻게 작성(ERD)하는지에 대해 배웠다. 앞서 말한 개념들은 전부터 공부하려고 했던 파트들이었는데 계속 미루다보니.. 이번 기회에 기말 시험도 대비할 겸 강의 내용을 복습하면서 정리해보려고 한다.
▼ Database Modeling (Design Phases)
데이터베이스 모델링 ?
- 간단히 말해서, 데이터베이스 스키마 설계 프로세스라고 할 수 있다.
Initial phase
- 잠재적(prospective) 사용자가 필요로 할 데이터, 즉 요구사항을 충분히 고려한다.
Second phase
- 개념적 데이터 모델을 선택 !
- 요구사항을 데이터베이스의 개념적 스키마(conceptual scheam)로 변환시킨다.
➜ 그렇게 도출된 개념적 스키마는 기능적 요구사항을 나타낸다.
( 데이터에 대한 연산 혹은 트랜잭션을 표현. )
- 요구사항을 데이터베이스의 개념적 스키마(conceptual scheam)로 변환시킨다.
Final phase
- 그렇게 생성된 추상적인 데이터 모델을 구체화시킨다.
- Logical design
: 데이터베이스 스키마(schema)를 결정한다.
➜ 개념적 스키마를 논리적 스키마에 대응시킨다.
➜ 주어진 상황에 있어서 스키마에 적합한 집합이 무엇일지 생각 !
ex) 사업과 관련된 것이라면, 데이터베이스에 기록해야 할 'attributes' 가 무엇일지?
컴퓨터 과학과 관련된 것이라면, 무슨 관계형 스키마를 설계해야 하며 다양항 스키마들 속에서 'attributes' 을 어떻게 분배해야 할지? - Physical design
: 논리 데이터 모델이 데이터 저장소로서 어떻게 컴퓨터 하드웨어에 표현될 것인가를 결정한다.
- Logical design
- 데이터베이스 스키마를 설계할 때에 주의해야 할 점
- Redundancy : 데이터들의 중복으로 인해 데이터들의 일관성을 유지하기 힘들어질 수 있다.
- Incompleteness : 설계가 잘못되면 기업의 특정 부분을 모델링하기 어려워질 수 있다.
- Redundancy : 데이터들의 중복으로 인해 데이터들의 일관성을 유지하기 힘들어질 수 있다.
▼ E-R Model
E-R Model (Entity Relationship Model)
- 'Entities' 와 'Relationships' 의 집합.
- Entity
: 다른 오브젝트로부터 구별될 수 있는 오브젝트를 말한다.
➜ 'Attributes' 의 집합. - Relationship
: 'Entity' 들 간의 관계를 의미한다.
- Entity
- E-R Model은 크게 다음 세 가지로 구성되어 있다.
- 엔티티 집합(Entity sets)
- 관계 집합(Relationship sets)
- 속성(Attributes0
- ER model은 데이터베이스의 전체적인 logical structure를 ER diagram이라는 직관적인 형태로 표현 가능하다 !
Entity Sets
- 같은 타입, 즉 같은 속성(properties)를 공유하는 엔티티(entity)들의 집합이다.
- instructor = (ID, name, salary)
- course = (course_id, title, credits)
- 'Attributes' 의 하위 집합(name, salary, etc.)은 'entity sets' 의 기본키(primary key)를 형성한다.
➜ 즉, 하위 집합의 각각의 요소들은 고유하게 식별 가능하다.
ex) 이름이 같거나 월급이 같더라도 누가 어떤 사람인지 구별 가능하다.
▼ ERD
Entity Relationship Diagram
- 읽히는 그대로 'Entity' 와 'Relationship' 에 중점을 두는 데이터베이스 구조(structure)를 직관적으로 볼 수 있게 그려놓는 '다이어그램(Diagram)' 이다.
Entity sets
- 사각형(rectangle)으로 표현하며, Primary key attributes는 밑줄(underline)을 쳐서 표현한다.
Relationship Sets
- 줄(line)을 그어 엔티티들 간의 관계를 표현한다.
- 단, 엔티티와 엔티티가 직접 연결되는 것이 아니라 엔티티들 사이에 연관된 또다른 속성(attribute) 데이터가 있을 수 있다.
- 아래에서 다이아몬드로 그린 <Enrolled in>가 엔티티 타입(type)인 'Student'와 'Course' 사이에 존재하는 '관계의 타입(Relations type)' 이다.
- 'Attributes' 와 함께 'Relationship sets' 을 그리면 다음과 같다.
Roles
- 'Relationship set', 즉 관계에 대한 설명이 필요할 때 유용하다.
Relationship Set의 차수(Degree)
- Binary relationship
➜ 두 개의 'entity set' 을 포함. - 세 개 이상의 'entity sets' 를 포함하는 'relationship' 은 드물다.
- Non-binary relationship sets
➜ 세 개의 관계(ternary relationship)으로 이루어지는 E-R Diagram을 말한다.
Attributes
- Single-valued attribute
: 단 하나의 값으로 구성된 'attribute'. - Multivalued attribute
: 두 개 이상의 값으로 구성된 'attribute'.
- Derived attribute
: 또다른 'attribute' 로부터 파생된 'attribute'.
- Domain
: 각각의 'attribute' 에 해당되는 값들의 집합. - Attribute
: Entity 타입을 정의하는 속성(property)라고 할 수 있다.
- Key attribute
: Entity set에서 각각의 'entity' 를 고유하게 식별해주는 'attribute' 를 말한다.
➜ 밑줄을 쳐서 표현한다. (underlying lines)
- Composite attribute
: 다른 'attribute' 들로 구성된 'attribute'.
Mapping Cardinality(관계 차수) Constraints
- Cardinality constraints
: 'Relationship' 이 존재하는 두 entity 사이에 한 entitiy에서 몇개의 다른 entity와 대응되는지 나타내는 제약조건이다.
- One to One
One: "instructor" ➜ "student" 와 relationship <advisor>를 통한 관계가 많아도 하나이어야 한다.
One: "student" ➜ student와 마찬가지이다.
- One to Many
Many: "instructor" ➜ "student" 와 relationship <advisor>를 통한 관계가 0개 이상이어야 한다.
One: "student" ➜ "instructor" 와 relationship <advisor>를 통한 관계는 많아도 하나이어야 한다.
- Many to one
One: "instructor" ➜ "student" 와 relationship <advisor>를 통한 관계는 많아도 하나이어야 한다.
Many: "student" ➜ "istructor" 와 relationship <advisor>를 통한 관계가 0개 이상이어야 한다.
- Many to many
Many: "instructor" ➜ "student" 와 relationship <advisor>를 통한 관계가 0개 이상이어야 한다.
Many: "student" ➜ "istructor" 와 relationship <advisor>를 통한 관계가 0개 이상이어야 한다.
( 하지만, 엔티티 간의 관계가 둘다 0개일 경우는 드물다. )
- Total participation (2개의 선으로 표현)
: Entity set에 속해있는 모든 'entity' 는 'relationship set' 과 적어도 하나의 'relationship' 에 참여하고 있어야 한다.
➜ 아래 다이어그램의 경우, 모든 "student" 는 "instructor" 와 적어도 하나의 'relationship' 을 갖고 있다.
- Partitial participation
: 모든 엔티티들이 'relationship' 에 참여할 필요는 없다.
➜ 위의 다이어그램을 예로 들면, <adviser>의 'relationship' 에 대한 "instructor" 의 참여는 부분적이다.
- A minimum value of 1 ➜ "Total participation"
A maximum value of 1 ➜ 많아도 하나의 'relationship' 에 참여.
A maximum value of * ➜ 제한이 없다. (no limit)
아래의 다이어그램을 분석해보면,
"instructor" 는 0 이상의 학생을 <advise> 할 수 있고,
각 "student" 는 단 한 명의 <advisor> 만 가질 수 있다.
Weak Entity Sets (중요)
- 'Weak entity' 의 존재(existence)를 보장하기 위해서 'weak entity' 는 'strong entity' 에 의존한다.
- 'Weak entity set' 과 연결되는 'relationship set' 은 double diamond로 표현된다.
- 'Weak entity set' 의 Primary key는 여러 개일 수 있다.
( Not single primary key )
Extended E-R Features
- 사실 데이터의 복잡도가 증가할수록 기존의 (traditional) ER Model은 데이터베이스 모델링이 힘들다.
➜ 추가된 몇가지 새로운 개념(concepts)
- Specialization (특수화)
- Generalization (일반화)
- Aggregation (집단화)
- Specialization (특수화)
- Specialization (⭤ Genralization)
- "Top-down" 접근
➜ lower-level entity set은 연결된 higer-level entity set의 모든 'attribute' 와 'relationship' 을 상속하고, 몇 개의 'attribute' 를 추가하는 방식이다.
- Generalization (⭤ Specialization)
- "Bottom-up"
➜ 여러 entity sets 사이에서 공통되는 'attribute' 를 찾고, 공통된 'attribute' 만으로 구성된 'entity set' 을 생성하는 방식이다.
➜ 즉, lower-level entity를 먼저 생성하고 higer-lever entity를 생성하는 것이다.
- Aggregation
: 여러 개의 entity들 사이의 'relation' 이 단일 entity처럼 다뤄지는 방식이다.
E-R 설계시 고려해야 할 사항
- 오브젝트를 상징하는 attribute 또는 entity set 사용.
- 'strong entity set' 혹은 'weak entity set' 사용.
- 'binary relationship' 과 'ternary relationship' 중 무엇을 채택할지.
- Specializaiton, Generalization
➜ 설계에 대한 모듈성(modularity) 고려. - Aggregation
➜ 내부적인 구조에 대한 세부사항(details)를 신경쓰지 않고 집약된 entity를 단일 유닛(unit)처럼 다룰 수 있다.
Summary of Sysmbols used in E-R Notation
▼ UML
UML (Unified Modeling Language)
- 모델을 만드는 표준 언어이다.
- UML이 사용되는 경우
- 다른 사람들과의 의사소통 또는 설계 논의
- 전체 시스템의 구조 및 클래스의 의존성 파악
- 유지보수를 위한 설계의 back-end 문서
- 다른 사람들과의 의사소통 또는 설계 논의
- UML Class Diagram은 E-R Diagram과 일치하지만, 몇 가지 다른 점이 있긴 하다.
