DBMS(데이터베이스 관리 시스템) 설계 개요: ER Model
Conceptual Design Model: ER Model
ER Model Gives us a language to specify
- what information the db must hold
- what are the relationships among components of that information
Conceptual design 단계에서 사용되는 모델링 기법으로, 주관적인 디자인 때문에 주어진 시나리오가 다양한 모델로 표현될 수 있다.
그 중에서도, 좋은 DB 디자인을 구현하기 위하여 관계 스키마(Relational schema)를 분석할 필요가 있다.
- FD information and normalization techniques are especially useful in such analysis.
Entity
하나의 객체/튜플; real-world object distinguishable from other objects; described using a set of attributes
Attributes: each has an atomic domain: string, integers, reals, etc.
Entity Set
같은 테이블의 있는 튜플들의 집합; a collection of similar entities (i.e., all employees)
- All entities in an entity set have the same set of attributes (unless ISA hierarchies)
- Each entity set has a key
- Each attribute has a domain
[An entity set (Person) twice in one relationship]
[Entity Sets vs. Attributes]
- Manfs deserves to be an entity set because of the nonkey attribute addr.
- Beers deserves to be an entity set because it is the “many” of the many-one relationship ManfBy.
An entity set should satisfy at least one of the following conditions:
- It is more than the name of something; it has at least one nonkey attribute.
- It is the “many” in a many-one or many-many relationship.
Relations
if A, B are sets, then a relation R is a subset of A x B
- A={1,2,3}, B={a,b,c,d}; R = {(1,a), (1,c), (3,b)}
Relation은 다음 강의에서 세부적으로 다룰 내용이다.
Relationship:
- Entity Set 간의 관계; Association among two or more entities (i.e., Eric works in Dept.)
- Modeled as a mathematical set
[Attributes on Relationships]
- not necessary, but useful
[Binary Relationship]
[Multiway Relationship]
Relationship Set: collection of similar relationships
- store, person, invoice determines movie
- store, invoice, movie determines person
Constraints
Constraints play an important role in determining the best database design for an enterprise.
- An assertion about the database that must be true at all times
- Part of the database schema
- Very important in database design
Keys: social security number uniquely identifies a person
- Every entity set must have a key
- A key can consist of more than one attribute
- There can be more than one key for an entity set
- one key will be designated as primary key
Single-value constraints: a person can have only one father (many-one relation; ppl have a father: Y/N)
- At most one value play a particular role
- An attribute of a entity set has a single value
- we can specify if the value must be present or can be missing (represented with say NULL or -1)
- example in real-estate domain
- price vs. house-style
- A many-one relation implies single value const.
Referential integrity constraints: if you work for a company, it must exist in the database
- Ref. int. constraint: exactly one value exists in a given role
- An attribute has a non-null, single value
- However, we more commonly use such constraints to refer to relationships
- the Referential Integrity Constraint on relationships explicitly requires a reference to exist
- i.e., a dangling pointer in C/C++
Domain constraints: peoples’ ages are between 0 and 150.
General constraints: all others (at most 50 students enroll in a class)
Key Constraints
Participation Constraints
관계를 맺는 두 Entity Type에 대해 한 개체의 존재가 다른 개체의 존재에 의존하는지 여부를 나타내는 제약조건으로, 하나 또는 그 이상의 개체가 참여한다.
- 가령, 직원은 여러 회사에서 무조건 일하지 않아도 괜찮으나, 회사는 직원이 무조건 있어야 한다 (전체 참여: Total)
The participation of Departments in Manages is said to be total (vs. partial)
- Every did value in Departments table must appear in a row of the Manages table (여기서 SSN은 null이 아니다).
For example, every department has a manager.
Overlap Constraints(중첩 제약조건)
다수 하위클래스 속할 수 있는지; Can Joe be an Hourly_Emps as well as a Contrat_Emps entity? (Allowed/disallowed)
Covering Constraints(포괄 제약조건)
적어도 하나 하위 클래스에 속해야하는 지; Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? (Y/N)
Foreign key constraints(외래키 제약조건)
두 테이블 사이의 관계를 선언함으로써, 데이터의 무결성을 보장해 주는 역할을 한다.
외래 키 관계를 설정하게 되면 하나의 테이블(외래 키 테이블)이 다른 테이블(기준 테이블)에 의존하게 된다.
‘외래 키 테이블’에 데이터를 입력할 때는 꼭 ‘기준 테이블’을 참조해서 입력하므로, 반드시 ‘기준 테이블’에 존재하는 데이터만 입력이 가능하다.
Some constraints (i.e., functional dependencies) cannot be expressed in the ER model.
Conceptural Design 구조
많은 데이터 구문(data semantics)이 사용되지만, 몇몇은 ER Diagram에서 사용될 수 없다.
Weak Entities(약한 개체)
Entity sets are weak when their key attributes come from other classes to which they are related
- Weak: Entity set의 각 Entity가 Unique하게 인지되기 위해서 Entity set에서 key를 참조해야 하는 경우
자신의 key attribute가 없는 entity type (i.e., 어떤 강의에서 분반은 자신의 key attribute이 없고 강의 테이블에 의존한다); can be identified uniquely only by considering the primary key of another (owner) entity
- one-to-many relationship (one: owner)
- total participation
Weak Entity Sets
Don’t Overuse Weak Entity Sets
Use them when there is no global authority capable of creating unique ID’s.
- i.e., it is unlikely that there could be an agreement to assign unique player numbers across all football teams in the world.
ISA(‘is a’) Hierarchies
ISA = subclasses = special case = fewer entities = more properties
Properties: attributes, relationships, etc.
- A ISA B: every A entity is also considered to be a B entity.
- 상위클래스(Superclass)-하위클래스(Subclass)의 관계이다.
객체 지향 세계에서 객체는 각각 하나의 클래스에 따로따로 존재하고, 서브클래스는 슈퍼클래스의 속성을 상속한다.
대조적으로 E/R 엔터티는 속한 모든 하위 클래스에 구성 요소가 있으며, 이는 관계로 전환할 때 중요하다.
Aggregation(집단화)
- 수강: a distinct relationship with a descriptive attribute
- 강의: 각 수업은 하나의 학생이 존재해야 교수가 강의할 수 있다.
Used when we have to model a relationship involving (entity sets and) a relationship set
- Treat a relationship set as an entity set for purposes of participation in other relationships
쉽게 말해, Entity - Relationship Set 간의 관계로, Entity만으로 특정 상황을 명확히 표현하기 어려울 때 Aggregation을 사용한다.
Design Principles
Faithful
Whatever relationships are asserted shuold make sense givne what we know about the part of the real world being modeled.
- i.e., if we define a relatinonship Stars-in between Stars and Movies, it should be a many-many relationship.
Avoid redundancy
살짝 헷갈릴 수 있으니, 다른 예시를 하나만 더 살펴보자.
- 이 디자인은 각 제조업체의 주소를 정확히 한 번 제공한다. This design gives the address of each manufacturer exactly once.
- 이 디자인은 맥주 제조업체를 속성 및 관련 엔터티로 두 번 나타낸다. This design states the manufacturer of a beer twice: as an attribute and as a related entity.
- 이 디자인은 각 맥주에 대해 제조업체의 주소를 한 번씩 반복한다. 제조자를 위한 맥주가 일시적으로 없으면 주소를 잃는다. This design repeats the manufacturer’s address once for each beer; loses the address if there are temporarily no beers for a manufacturer.
KISS
가장 간단한 형태로 관계도 표현하는 방법
Conceptual Design Using the ER Model
개체-속성 선택
상기 모형에서, Works_In2는 한 직원이 어느 부서애서 “2달 이상 기간”이라는 입력을 적용하지 못한다.
- “기간”이 아니라 from과 to 각각의 “일자”를 입력해야 한다.
기간으로도 입력을 받기 위하여, Duration이라는 개체에 속한 속성으로 from, to를 primary keys로 등록한다.
따라서, 어떠한 정보를 개체에 속한 속성으로 만들지, 따로 하나의 개체로 만들지 상황에 맞게 선택해야 한다.
개체-관계 선택
어떠한 속성을 관계의 속성으로 만들지 (i.e., a manager gets a separate discretionary budget for each dept.)
개체의 속성으로 만들지 상황에 맞게 선택해야 한다 (i.e., a manager gets a separate discretionary budget that covers all managed depts)
이진관계(binary)-삼진관계(ternary) 선택
[이진관계]
[삼진관계]
상황에 맞는 이진관계 혹은 삼진관계를 선택해야 한다.
삼진관계 모형에는 하나의 에로사항이 있다.
만약 Employee마다 오로지 한 개의 Policy만 행사하는 경우, 각각 한 명의 Dependent만 Cover 가능할 것이다.
그렇다면, 여기서 이상적인 상황은 Employee마다 여러 개의 Policies를 활용해 여러 명의 Dependents를 Cover하는 상황일 것이다.
이 에로사항을 타파하기 위하여 이진관계를 사용해 Purchaser()
상기 예시에서는 두 개의 이진관계가 하나의 삼진관계보다 더 효과적으로 동작하는 것을 보여준다.
삼진관계를 이진관계들로 표현할 때 값이 달라질 수 있어서, weak entity를 사용해 식별 관계로 바꿔주는 것이 안전하다.
다음 시간에는 관계 모델; ER to Relations에 대해 알아보자.
Reference
Database Management Systems by Raghu Ramakrishnan and Johannes Gehrke
댓글남기기