[DBMS] 데이터베이스 모델링

Updated: 2024.04.29

Categories: Database

📌 개인적인 공간으로 공부를 기록하고 복습하기 위해 사용하는 블로그입니다.
정확하지 않은 정보가 있을 수 있으니 참고바랍니다 :😸
[틀린 내용은 댓글로 남겨주시면 복받으실거에요]

Database Management System

데이터베이스란 ?
- 일상 생활 속에서 데이터베이스라 할 수 있는 것들
  - = 사진, 연락처, 캘린더, 엑셀 등등
- 다양한 곳에서 데이터 베이스를 활용함
- 데이터는 다양한 방식으로 들어올 수 있음
이렇게 되면 검색이나 조작이 힘들고 데이터의 양이 많아지면 다루기 힘들어짐. > 관리못함

✔️ 그래서 결국 데이터는 일관된 형식으로 저장해야한다.
데이터 베이스의 중요 특징
1. 중복방지 = 중복되면 용량이 커지고 공간이 부족해짐, 중복이 안되면 관리가 용이
2. 데이터무결성 유지 : 주소가 변경되면 모든 기록에서 일관되게 갱신해야함.
  정확성과 일관성을 유지하여야 한다. > 만약 깨질경우 엄청나게 큰 문제 발생
  
  데이터 베이스가 무결성 유지가 용이하다는 것은 테이블에 들어올 때 형식에 맞지 않으면 못들어오게 막을 수 있다는 것.
3. 데이터 검색 및 조작 : 필요한 정보를 쉽고 빠르게 찾아 볼 수 있다.
4. 데이터 공유 : 동시에 여러사람이 같은 데이터를 보고 함께 사용할 수 있음
데이터베이스 매니지먼트 시스템 (DBMS)
1. DBMS의 주요기능
  - 데이터 저장 및 관리
  - 데이터 검색 및 조작
  - 데이터 보안
  - 데이터 백업 및 복구
  - 데이터 동기화
2. 대표 DBMS
  - MySQL
  - Oracle
  - Microsoft SQL Server
  - PostgreSQL

🔎 참고)
✔️ 가장 해킹하기 쉬운 접근은 물리적 접근이라서 데이터센터의 위치는 절대 공개하지 않는다.
✔️ 그리고 보통 데이터 센터는 분산되어있다고 함.
✔️ 예전에 카카오 데이터센터 화재났을때 처음엔 위치도 기사에 안나왔다가 길어져서 나왔다고 함..!

데이터베이스의 특징
- 통합데이터
- 저장데이터
- 공유데이터
- 운영데이터
- 실시간 접근 - 언제든지 접근 가능해야함, 은행은 매일 점검시간이 있긴 함.
- 계속 변화
- 내용기반참조
- 계속공유

Entity

Entity의 특징
1. Entity는 유일한 식별자가 있어야 함.(PK)
2. 영속적으로 존재하는 두개 이상의 인스턴스 집합이어야 함.
3. 다른 Entity와 관계를 가져야 한다.
4. 반드시 1개 이상의 속성을 포함 해야 함.
Entity의 명명법
1. 가능하면 현업 업무에서 사용하는 용어를 사용
2. 약어 사용X
3. 단수 명사 사용!!!!! - 복수 사용시 전부 다 복수
  - 사용자는 보통 member라고 명명하는데 -members 절대 안됨
  - 모든 Entity에서 유일한 이름 부여해야 함. 중복 절대 안됨!
  - Entity 생성 의미에 맞는 이름부여

속성

`속성은 인스턴스 변수라 할 수 있음`

상품 = Entity
상품명, 제조사, 정가, 판매가, 제조국가 등등 = 속성(Attribute)

`속성의 고려사항`

항상 동일한 값이 들어와야 하는 것은 속성에 넣지 않는 것이 좋음
1. 그러나 단 하나라도 다른 데이터가 들어올 여지가 있으면 속성으로 넣는 것을 고려해야 함.
엔티티에 필요한 속성인지?
1. 병원에서 환자의 mbti 정보를 속성으로 넣는 것은 쓰일 확률이 없으므로 사용하지 말아야 한다.
분리할 수 있는 것은 분리하는 것이 좋음 = 정규화

반대로, 성능이슈로 인해 속성으로 다시 넣는 과정은 =비정규화

`속성은 하나의 값만 가져야 함 = 다중 속성 불가`

다중속성 사용할거면 NoSQL사용권장

고객의 primary key를 가져와서 활용하고 있음.
1. 고객 정보는 고객 primary키로 가져와서 관리할 수 있기 때문에
2. 기본 키는 안 바뀌지만 갱신할 때 문제 생길 수 있음 ⇒개명을 했을 때는 개명한 사람의 이름이 바뀌어야 함 아니면 전체 데이터를 사용 못함.
3. 여러 값이 들어 갈 경우 새로운 엔티티를 생성해서 다중 값 없애야 함.

`속성은 하나의 독립적인 의미를 가져야 함`

예1)

주문일자와 등록일자는 서로 동일한 의미를 가지므로 하나로 통합해서 사용

예2)

주민등록번호 > 생년월일+뒷자리 7개는 전체만이 의미가 있으므로 분리하면 안됨.

속성의 분류

1. 특성에 따른 분류

기본속성 : 업무분석을 통해 바로 정의한 속성
설계속성 : 원래 업무상 존재하지는 않지만 설계를 하면서 도출해내는 속석
파생속성 : 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성

기본속성과 설계속성은 구분짓지 않는 경우가 많음, 용어를 외울 필요 없음

2. 엔터티 구성방식에 따른 분류✨✨

PK속성 : 엔터티를 식별할 수 있는 속성
FK속성 : 다른 엔터티와의 관계에서 포함된 속성
일반속성 : PK, FK에 포함되지 않은 속성

하나의 부서를 나타내는 고유값인 primary key를 (부서번호) 사원도 부서의 primary key값을 동일하게 가지고 잇음. = 외래키
사원의 001 옆에 부서라는 키를 참조키로 사용하고 있다는 설명이 있을 것이고 부서로 넘어가서 001을 확인하면 경영지원팀임을 알 수 있음.

속성의 명명

해당 업무에서 사용하는 이름을 부여한다.
서술식 속성명은 가급적 사용하지 않는다.
약어 사용은 가급적 제한한다.
전체 데이터모델에서 유일성을 확보하는 것이 좋다.

관계✨✨✨✨✨✨✨

관계란 엔티티들이 서로 상호 연관성을 가지고 있는 상태

테이블 간의 관계 (테이블 간의 관계는 바로바로 찾을 수 있어야 함)
- 일대일
- 일대다
- 다대다

존재에 의한 관계

부서와 사원의 테이블 간 관계는 일대 다. (한 명의 사원은 여러 부서에 속할 수 있는지?
✔️ 하나의 부서는 여러 명의 사원에 속해지는 지를 생각해보면 됨)

행위에 의한 관계

고객과 주문은 일반적으로 일대다

배달의민족서비스에서는 다대다 도 생김…(하나의 주문에 여러 고객이 들어오는 경우가 생겨서)

관계명(Membership) : 관계의 이름
관계차수(Cardinality) : 일대일(1:1) , 일대다(1:M), 다대다(M:N)
관계선택사양(Optionality) : 필수관계, 선택관계
- 고객과 주문 관계 : 고객은 주문을 선택, 주문은 반드시 고객이 있어야 함.

식별자

Primary key

기본 키는 하나 이상이 있어야 함 - 여러 개가 올 수 는 있지만 복잡해져서 잘 없음.

하나의 부서를 나타내는 고유 값인 primary key와

사원은 primary key값을 동일하게 가지고 있음. = 외래 키

식별자의 특징

특징	내용	비고
유일성	엔터티 내의 모든 인스턴스들을 유일하게 구분할 수 있어야 함	웹사이트 회원은 개인마다 이메일주소가 달라야한다. 중복된 이메일을 사용해서는 안된다.
최소성	식별자의 개수는 유일성을 만족하는 최소의 수를 가져야 함	이메일만으로 각 개별 회원을 구분해낼 수 있다면 굳이 계정명을 새로 받아 식별자로 구성할 필요는 없다.
불변성	식별자의 값은 정해지면 변하면 안됨	한번 가입한 메일은 회원정보 수정을 통해 바꿔서는 안된다.
존재성	식별자의 값은 null이 될 수 없음	이메일정보가 없는 회원은 존재하면 안된다.

불변성
1. 이메일주소를 기본 키로 사용할 때 이메일에 의존성을 가지게 됨.
2. 메일은 외부의 데이터를 가져와서 값을 사용하는 거기때문에 의존성이 생기게되서 이런경우에는 PK로 사용하지 않음.
3. 메일주소나 전호번호는 변경이 가능하기때문에 그런 값으로 기본키를 지정하지 않음.
4. 불변성을 만족할 수 없음.
식별자는 null이 될 수 없지만 외래키는 null이 될 수 있는가? - 일반적으로는 가능
1. null이 된다는 건 참조할 수 있는 값이 없다는 것.
2. 누군가 작성자가 피드에 글을 남겻고 다른 누군가 댓글을 남겼고 그 다른 누군가가 탈퇴할 경우
3. 댓글이 지워지는가 ?⇒ 안 지워지는 경우가 대부분
4. ✨우리가 삭제하는 데이터는 사이트의 데이터베이스에서 지우지 않음. 기본적으로 non delete임
5. 테이블에 어떤값이 delete라고해서 그 값을 지우지 않음 , 데이터베이스를 삭제하는 경우는 매우 드물다.
6. 상태를 나타내는 속성을 하나 더 만들어서 활성화, 비활성화 등의 상태로 둘 수 잇음. 또는 쓰레기통같은 것을 만들어서 거기에 둘 수도 있음

식별자 분류

대표성 여부

주식별자: 엔터티 내에서 각 인스턴스들을 구분할 수 있는 구분자이며, 타 엔터티와 관계를 연결할 수 있는 식별자 (ex: 주문번호, 사원번호)
- 주식별자가 없는경우는 거의 없음 , 그냥 not null로 가지고 있음, 주식별자로 다쓰게됨
보조식별자: 엔터티 내에서 각 인스턴스들을 구분할 수 있는 구분자이나 대표성을 가지지 못해 관계연결을 못하는 식별자 (ex: 전화번호 : 전화번호는 각 개인마다 유일하긴 하나 자주 바뀔 수 있어서 불변성을 만족하지 못함)
- 보조식별자는 안쓰는경우가 대부분임.

스스로 생성 여부✨

내부식별자: 엔터티 내부에서 스스로 생성되는 식별자 (ex: 게시판글번호)
- 기본키는 우리가 만드는게 아니라 스스로 생성
- 내가 직접하는 경우 없음.
- 보통 1부터 시작해서 자기 자신을 증가하여 번호를 만듬. Auto increasment
외부식별자: 타 엔티티와의 관계를 통해 들어오는 식별자 (ex: 댓글 엔티티의 원본게시물번호)
- =외래키 , 외래키에 대한 설명, 참조해야 되는 값을 가져오는 것

식별자와 비식별자 관계

Hezzi