2023. 4. 8. 03:54ㆍDataBase
Chapter 1 entity set
엔티티(entity)란?
고유한 속성을 가지는 개체를 말한다.
예를 들어 학생 엔티티는 (학번, 이름, 성별, 전공) 등으로 구성되며
제품 엔티티는 (제품번호, 제품명, 가격, 재고량, 출고일자) 등으로 구성된다.
각 엔티티는 데이터베이스에서 고유한 식별자(primary key)를 가지며 이를 이용해 엔티티 간 관계를 정의한다.
entity는 tuple과 같다
tuple들의 집합이 entity set이다
예시로 투플이 여러개 있으면 하나로 묶어주는 Product, Person 등이 entity Set이라 칭한다.
이는 아래에 설명할 ER다이어그램에서 네모상자로 표현한다.
DB 설계 과정
- 필요조건 분석
- 무엇이 저장될 것인가?
- 저장 데이터를 어떻게 활용할 것인가?
- 그 데이터들을 어떻게 다룰 것인가?
- 데이터를 접근할 수 있는 방법? 혹은 누가 접근?
- 보안 이슈
- 실제 구현 전 1번의 요소를 어떻게 설계할 것인지 추상적인 개요 설계
- DB 영역에서 구체적인 상위 수준 개요를 짠다
- 비전문가 영역 / 전문가 영역 간 의사소통을 위한 디자인 설명
- 이 때 ER 다이어그램 사용
- 마지막
- 실제 로직 데이터 베이스 디자인
- 물리적 데이터베이스 디자인
- 보안 이슈 디자인
위의 과정들을 간소화하고 구체적인 의사소통 방식인 추상적인 개념 E/R Model & Diagrams 을 사용한 것이다.
엔티티 간 연결고리와 관계를 표현하며 각 엔티티의 attribute 역시 표현한다.
ER diagram
- 엔티티(Entity): ER 다이어그램에서 엔티티는 데이터베이스에서 저장되는 개체를 나타냅니다. 엔티티는 사람, 제품, 주문 등과 같은 실제 세계의 객체나 개념을 나타냅니다.
- 관계(Relationship): 엔티티 간의 관계를 나타냅니다. 관계는 일대일, 일대다, 다대다와 같은 다양한 유형이 있습니다. 관계는 라인으로 나타내며, 라인의 양쪽 끝에는 관계에 참여하는 엔티티 이름이 표시됩니다.
- 속성(Attribute): 엔티티가 가지는 고유한 특성을 나타냅니다. 예를 들어, "학생" 엔티티는 "학번", "이름", "전화번호" 등의 속성을 가질 수 있습니다. 속성은 엔티티의 사각형 안에 표시됩니다.
ER 다이어그램은 엔티티, 관계, 속성 등을 포함하는 요소들을 시각적으로 표현하며, 이를 통해 데이터베이스의 구조와 상호작용을 파악할 수 있습니다. ER 다이어그램을 사용하여 데이터베이스를 설계하면, 데이터베이스의 구조를 쉽게 파악할 수 있으며, 데이터의 중복이나 불일치를 방지하고, 데이터 관리를 효율적으로 할 수 있습니다.
- ER 다이어그램에서 색깔은 중요하지 않으나 도형이 중요하다
- Product는 Entity Set이며 원은 attributes이다
- name은 기본키이다(밑줄)
- Product의 attributes를 보여주는 것이기에 직선으로 연결함
- 스키마로 표현시 Product(name, price, category)
- 또한 ER 다이어그램에서 tuple은 표시하지 않는다
Xbox혹은 My Little Pony Doll은 Entity이며 Product는 엔티티 셋이다
각 엔티티들은 Attributes를 가지고 있다.
Key는 엔티티 셋에 속해있는 모든 tuple들을 구별할 수 있는 유일한 방법
Minimal Set : Primary Key는 밑줄이다.
후보키들이 다양하게 있을 수 있지만 ER 다이어그램에서는 하나의 Primary Key만 권장
Chapter 2 Relationship
Relationships
Product와 Company라는 Entity Set이 있는데 이 두 엔티티셋의 관계를 Makes라는 마름모꼴로 표현한다.
예시로 Makes(Pname, Cname)
Product의 외래키, Company의 외래키로 지정해주었다.
두 테이블을 조인한 결과로 6개의 투플이 존재하는데
모든 결과가 아닌 subset만 가져와서
어떤 두개의 엔티티 셋을 연결하는 realationship은 하나만 존재한다.
왜냐하면 Product와 Company의 키를 가지고 makes를 구성하기 때문에 유일할 수 밖에 없다.
유일하게 구별할 수 있는 attributes인 Pname과 Cname을 가지고 조인을 했다고 생각을 하면 당연히 모든 투플들 역시 유일하게 구별 가능할 것이다.
다음은 어떤 사람이 어떤 상품을 언제 구매했는지 알 수있는 ER다이어그램이다.
각 attributes는 유일한 것들로 키를 지정했다.
Person과 Product가 조인시 유일한 투플들만 있기에
결국 어떤 사람은 똑같은 물건을 하루에 단 한번만 구매할 수 있다(날짜가 유일해야하므로)는 제약조건이 생기게 된다
그렇기에 위와 같이 표현한다면
Purchase라는 Entity Set을 통해 생산, 구매, 사람 등에 대한 별 다른 제약조건 없이 DB를 이용할 수 있다.
Chapter 3 Relationship - Multiplicity
Multiplicity of E/R Relationships
엔티티 간의 관계에서 한 엔티티가 다른 엔티티와 관계를 가질 때, 그 관계의 강도와 종류를 나타내는 개념
이를 통해 어떤 엔티티가 다른 엔티티와의 관계에서 몇개의 데이터를 가지는지, 또한 이러한 데이터들 간의 관계를 파악할 수 있다.
- One-to-One(일대일 관계) : 학생 한명이 교실 한개에 할당되는 경우, 학생 한명이 학번 하나를 할당 받는 경우 등이 일대일 관계가 성립한다. 이의 경우 한번에 하나의 데이터만 가진다
- Many-to-one(다대일 관계) : 각 학교는 여러개의 교실을 가지지만 각 교실은 하나의 학교에만 속한다. 교실 엔티티는 학교 엔티티의 외래키를 가지며 학교 엔티티는 여러개의 교실 엔티티와 매칭 된다. 다대일 관계에서는 많은 수의 레코드가 속한 엔티티가 일반적으로 다쪽에 위치하고 적은 수의 레코드가 속한 엔티티가 일쪽에 위치한다. 여기서 다쪽의 엔티티의 레코드가 삭제되면 일쪽의 엔티티 레코드는 삭제되지 않는다. 예시로 학교가 폐교되어 삭제되더라도 해당 도시 엔티티는 삭제 되지 않는다.
- 화살표 ->가 1개를 의미, 없으면 n개
- One-to-Many(일대다 관계) : 한 교실에 여러 학생이 들어갈 수 있는 경우 일대다 관계가 성립한다. 이 경우 교실은 여러 학생을 가질 수 있지만, 각 학생은 하나의 교실만 가질 수 있다.
- 화살표 ->가 1개를 의미, 없으면 n개
- Many-to-Many(다대다 관계) : 학생들이 여러 교실에 들어갈 수 있고, 각교실에는 여러학생이 들어갈 수 있는 경우 다대다 관계가 성립한다. 이 경우에 학생과 교실 간의 관계는 많은 데이터를 가지며, 이러한 데이터들은 많은 다른 데이터와 연결될 수 있다.
Multi-Way
1:1, n:1, n:n 등 .. 다중 연관성을 표현
n:1 (Person)
Person의 화살표가 의미하는 바를 보면
여러명의 사용자가 특정한 물건을 특정한 매장에서 구매하는 것이 가능하다
Store가 n개 있는데 product와 Person을 하나씩 지정하겠다는 의미
이 관계를 통해서 어떤 매장 하나를 지정한 후 구매자가 어떤 제품을 샀는지 특정할 수 있는데 문제점이 있다면 Product와 Person이 각각 하나씩만 존재할 수 있기에 이 관리체계에서는 여러 사용자와 여러 물건에 대한 매칭이 불가능
모든 사람이 물건을 사는데 최소한 하나의 매장에서 물건을 사는 경우?
n:1도 가능하며 n:n 역시 가능하다
이 복잡한경우는 표현을 할 수 없다.
다중 연관성의 관계를 Binary(이진화)하는 방법
이것을 어떻게 변환할까?
Purchase(구매내역)은 Product, Store, Person의 릴레이션이 있다.
*of와 같은 관계가 정의 되었고 Purchase엔 date라는 추가 정보도 연결 되어있다.
누가 어느 가게에서 어느 물건을 샀는지 판단하기 위해서는 위의 ER 다이어그램의 과정을 통과해야만 한다.
우리는 Multi-way를 사용할 것이냐 Entity+Binary를 사용할 것이냐?
Multi-way는 3개의 엔티티가 연결되어있어 관계 표현에 제한적이다
왜냐하면 하나의 제품을 고정해두고 나머지 두개를 따져야하는 상황들이 생길 수 있어 관계 표현 복잡도가 제한되어 있음
Entity + Binary
엔티티를 하나 추가하고 바이너리 관계를 맺게 되면 Purchase와 Product \ Purchase와 Store \ Purchase와 Person 와 같이
좀 더 유연한 표현이 가능해진다.
화살표의 관계를 각각 지정할 수 있기 때문에 2번째 Case를 잘 활용할 수 있도록 하자
그렇다면 A의 경우는 언제 사용되는가?
세개의 entity가 공유하고 있는 계약서를 쓴다 하면 유일한 사건이기에 저렇게 표현할 수도 있다.
다중 연관성
Product는 n개가 있을 수 있고 company는 하나만 있을 수 있다.
즉 한 회사는 여러개의 Product를 가질 수 있고
Company엔 이름이 있고 Product엔 price, name, category 라는 attributes 정보를 파악할 수 있다.
또한 Person은 n명이 있을 수 있고 company는 하나만 있을 수 있다.
Perosn엔 address, name, ssn이 있고 company는 name, stockprice라는 attributes 정보를 파악할 수 있다.