Notice
Recent Posts
Recent Comments
Link
«   2025/05   »
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Tags
more
Archives
Today
Total
관리 메뉴

어리바리 신입 개발자의 얼렁뚱땅 개발 기록 ✨

23.05.15 / 데이터 모델링 & 데이터베이스의 구성 본문

Database/MYSQL

23.05.15 / 데이터 모델링 & 데이터베이스의 구성

낫쏘링 2023. 5. 15. 16:19
728x90

모델링?

- 현실에서 사용하는 복잡한 데이터를 어떻게 컴퓨터의 DBMS에 옮겨 놓을지 결정하는 과정

과거 : 프로젝트의 규모 작았고, 사용자의 요구 사항도 단순했음

현재 : 프로젝트의 규모 크고, 사용자의 요구 사항도 복잡해짐

 

데이터 모델링 - 건축

현실 세계 -> 개념 세계 -> 컴퓨터 세계로 표현

EX ) 네이버 로그인 -> 회원 아이디, 비밀번호, 로그인 날짜, IP 등... -> 테이블 형태

 

특징

1. 추상화 : 현실 시계를 간략히 표현

2. 단순화 : 누구나 쉽게 이해할 수 있도록 표시한다.

3. 명확성 : 명확하게 의미가 해석되고, 한 가지 의미만 가져야 한다.

 

현실에서 쓰이는 것을 테이블로 변경하기 위한 작업이다.

변환 대상 : 실체가 있는 대상 + 행동까지 변환 가능

 

나 > 올리브영 - 직원 상담, 상품을 구매 (현실)

- 상품 테이블 : 상품 일렬 번호, 상품명, 제조 일자, 회사, 가격

- 직원 테이블, 고객 테이블, 구매 테이블, 배송 테이블

 

사람의 신분을 증명하는 신분증

- 사람 정보_테이블 : 주민번호, 이름, 주소, 지문

 

모델링 단계

보통 크게 3개의 단계가 있음

 

데이터 베이스 생명 주기

- 사용자 요구 사항에 의해 최초 구축, 필요에 따라 개선 도는 재구축

- 단계 : 요구 사항 수집 및 분석 - 설계 - 구현 - 운영 - 개선

 

개념적 모델링 : 업무 분석 단계에 포함

- 사람이 이해할 수 있도록 현실 세계를 개념적인 형태의 모델링 진행

- E-R 다이어그램 작성

요구 사항 수집, 분석 > 결과 > 핵심 개념 즉, 개체라고 하는 것을 추출. 개체들의 관계를 정의해서 E-R 다이어그램을 만든다.

 

논리적 모델링 : 업무 분석 후반부와 시스템 설계

- 개념적 구조를 논리적 형태로 모델링

- 데이터베이스의 논리적인 구조로 표현

업무에 연관이 있는 테이블들 -> 관계 맺어줘야함  : 관련 있는 두 테이블의 관계(Relation)

 

물리적 모델링 : 시스템 설계 후반부에 주로 진행

 

데이터 모델의 구성 요소

개체(Entiy)

- 사람이 생각하는 개념, 정보와 같은 현실 세계의 대상

- 개체와 게체 타입으로 분류할 수 있다.

- 개체 : 업무에 필요한 유용한 정보를 저장하고 관리하기 위해 영속적으로 존재하는 단위

- 개체들의 집합 : 개체 타입

ex) 홍길동 강사, 이길동 강사, 삼길동 강사 -> 개체 : 강사

속성(Attribute)

- 데이터의 가장 작은 단위

- 개체에서 관리하고자하는 더 이상 나눠지지 않는 최소 데이터 단위

- 개체가 가지는 동일한 성격, 특징 파악

ex) 홍길동 학생, 이길동 학생, 삼길동 학생 -> 개체 : 학생 / 속성 : 학번, 이름, 주소, 연락처, 전공, 학년 

관계

- 개체 간 관계 또는 속성 간 논리적 연결

- 개체와 개체가 맺고 있는 의미 있는 연관성

ex) 고객 - 상품 : 구매 --> 고객 개체와 상품 개체는 구매라는 관계가 있다.

고객테이블 : 부모 테이블 - 구매테이블 : 관계 테이블 - 상품테이블 : 자식 테이블

부모테이블 - KEY - 자식테이블

관계의 종류 : 1대1, 1대다, 다대다

 

직사각형 : 개체 / 타원 : 속성 / 마름모 : 관계 / 직선 : 링크(개체와 속성을 연결)

 

[ 데이터베이스의 구성 ]

[ 데이터베이스 스키마 ]

  • 데이터베이스의 전체 구조
  • 데이터베이스를 구성하는 릴레이션 스키마의 모음
* 스키마(Schema)
- 테이블의 구조 혹은 데이터의 구조
- 릴레이션이 어떻게 구성되는지, 어떤 정보를 담고 있는지 기본적인 구조를 정의한다.
- 테이블의 속성와 자료 타입에 대한 정보를 가지고 있다.

 

[ 데이터베이스 인스턴스 ]

  • 데이터베이스를 구성하는 릴레이션 인스턴스의 모음
* 인스턴스 : 스키마를 정의하고, 정의한 스키마에 따라서 실제로 테이블에 저장되는 데이터의 집합

 

[ 릴레이션 ]

릴레이션 : 테이블
애트리뷰트(속성) : 컬럼
Degree : 애트리뷰트의 수
식별자(키) : 유일성, null 불가능
튜플 : 속성이 쌓이는 데이터(row, 레코드)
카디널리티 : 튜플의 수 
Domain : 릴레이션에 포함된 각각의 속성들이 가질 수 있는 값들의 집합
  • 릴레이션은 중복된 튜플을 가질 수 없다.
  • 튜플을 식별하기 위해 KEY를 설정하여 유니크하게 식별 가능
  • 릴레이션에서 튜플의 순서는 중요하지 않다. - 정렬 기준이 다양하기 때문
  • 하나의 릴레이션에서 애트리뷰트의 이름은 중복될 수 없다.
  • 하나의 릴레이션에서 애트리뷰트의 순서는 중요하지 않다.
  • 애트리뷰트는 원자값(Atomic)을 가져야 한다.
[[ 도메인 정하기 ]]
- 하나의 애트리뷰트(속성)가 가질 수 있는 같은 타입의 원자값의 집합
- 애트리뷰트 : 하나의 릴레이션에서 맡은 역할에 대한 이름을 부여하는 것

ex) 만약, 동일한 도메인 이름이라면, 릴레이션에 표기할 때연락처 -> phone_num / 비상 연락처 -> emer_num (하나의 릴레이션에서 애트리뷰트의 이름은 중복될 수 없다.)

- 튜플은 각 애트리뷰트의 값으로 이루어진 행(row, list)이며, 값이 Null일 수 있다.
- 단, 필수 입력 값이 아니라면 Null 허용. / NOT NULL 이면, Null 값 불가능
- 애트리뷰트 리스트 작성 방법 : 테이블_이름(속성) -> 학생(학번, 이름, 주소, 연락처, 비상연락처)
- Null ? 값이 존재하지 않는다. / 값은 존재하는데, 아직 그 값을 알지 못한다.


[[ 관계형 데이터베이스의 제약 조건 ]]

[ KEY ]
키는 릴레이션에서 튜플들을 유일하게 구별하는 속성 또는 속성들의 집합
데이터베이스에서 조건을 만족하는 튜플을 찾거나, 순서대로 정렬할 때, 튜플을 서로 구분할 수 있는 기본이 되는 애트리뷰트
 - 기본 키(Primary key)
   기본 키 ⊂ 후보 키 ⊂ 슈퍼 키

   후보 키들 중 기본적으로 사용하기 위해 선택한 키
   중복된 값과 Null 값을 가질 수 없다.
   하나의 릴레이션에서 특정 튜플을 구별할 수 있는 유일한 속성.
 - 복합 키(Composite Primary key)
   기본 키의 역할을 할 수 있는 컬럼이 없다고 가정할 때 PK를 정의할 수 있음.
 - 대체 키(Alternate key)
   대체 키 ⊂ 후보 키

   후보 키가 둘 이상일 때, 기본키로 선택되지 못한 후보 키를 대체 키라고 한다.
   ex) 학생(학번, 이름, 주소, 연락처, 주민번호) -> {학번} : PK /  {주민번호} : AK 

 - 후보 키(Candidate key)
   후보 키 ⊂ 슈퍼 키
   릴레이션을 구성하는 속성들 중에서 튜플을 유일하게 식별할 수 있는 키
   즉, 기본 키로 사용할수 있는 속성들
   유일성 + 최소성 동시에 만족하는 속성 또는 속성들의 집합
   유일성 : 하나의 키 값으로 하나의 튜플만 유일하게 식별해야 한다.
   최소성 : 모든 레코드들은 유일하게 식별하는 데 꼭 필요한 속성으로만 구성해야 한다.
   ex) 학생(학번, 이름, 주소, 연락처, 주민번호) -> {학번}  {주민번호}
 - 슈퍼 키(Super key)
   유일성을 만족하는 속성 또는 속성들의 집합(최소성은 만족X - 후보 키와 다르게 불필요한 속성까지 포함 가능 - 이름)
   릴레이션에서 튜플을 유니크하게 식별할 수 있는 하나 또는 속성들의 집합
   ex) 학생(학번, 이름, 주소, 연락처, 주민번호) ->  {학번+주민번호} : 학번이나 주민번호 하나 만으로 충분히 식별 가능 하지만 둘을 합쳐두면 유일성은 만족하지만 최소성이 만족하지 않는다. / {학번+이름} 
 - 외래 키(Foreign key)
   다른 릴레이션의 기본키를 참조하는 속성 또는 속성들의 집합
   다른 릴레이션의 기본 키를 참조하여 테이블 간 관계를 표현하는 중요한 키
   단, Null은 허용한다.


[[ RDBMS의 제약 조건 ]]

제약 조건 : RDBMS에서 릴레이션들이 항상 지켜야 하는 사항

[ 포함된 제약 조건(implicit constraints ,내포) ]
- 릴레이션 자체가 가지고 있는 제약 조건
- 릴레이션은 중복된 튜플을 가질 수 없다.
- 릴레이션은 같은 이름의 애트리뷰트를 가질 수 없다.

[ 무결성 제약 조건(Integrity constraints) ]
무결성 : 데이터의 결함이 없는 상태
일관성과 정확성을 가지고 구축된 데이터베이스가 계속해서 무결성을 유지하려면, 데이터의 삽입, 삭제, 수정 시, 데이터의 제약 조건 준수 여부를 확인해야 한다.
 - 도메인 무결성 제약 조건
   애트리뷰터의 값은 정의된 도메인에 속한 값이어야 한다.
   ex) 학생R -> 도메인 : 학년 1~4까지, 애트리뷰트 : 20 불가능
   NOT NULL이 아닐 경우, Null 값 허용.
 - 개체 무결성 제약 조건(Entity)
   기본 키 제약
   기본 키를 구성하는 속성은 중복 값과 Null 값을 가질 수 없다. -> 유니크하게 식별 불가능하기 때문
 - 참조 무결성 제약 조건
   외래 키의 값은 Null이거나, 참조 릴레이션의 기본 키 값과 동일해야한다.
   단, Null을 입력하려면, Null 허용일 경우
   외래 키는 참조하고 있는 테이블의 기본 키에 없는 값을 외래 키로 가질 수 없다.

[ 키 제약 조건(key constraints) ]
서로 다른 튜플들은 같은 값의 키를 가질 수 있다.

[ Null value constraint ]
애트리뷰트가 NO NULL 이라고 명시되어 있다면, NULL값을 가질 수 없다.

[ CHECK 제약 조건(MySQL 8.0.16)]
애트리뷰트에 들어갈 수 있는 값을 제한한다.
숫자 비교, 문자 비교 가능
입력되는 값이 CHECK 조건과 맞지 않으면, 에러가 발생한다.
컬럼명 데이터타입 CHECK(컬럼명 조건)
ex) 회원 테이블 생성 - 출생년도 / 나이 제한
      birth_year INT CHECK(birth_year >= 1950 AND birth_year <=2020)
      age INT CHECK(age >=20)

 

 

 

728x90

'Database > MYSQL' 카테고리의 다른 글

23.05.23 / 데이터베이스 설계 & eXERD  (0) 2023.05.22
23.05.16 / JOIN & NULL 조회  (0) 2023.05.16
23.05.15 / 내장 함수, MySQL 변수  (0) 2023.05.15
23.05.15 / DBeaver(디비버)  (0) 2023.05.15
23.05.15 / 데이터 타입  (0) 2023.05.15