프롤로그
코드같은 거 짤 때, 우리는 그냥 코딩 습관에 길들여져 있어서 일단 코딩하기 시작한다. 그러다보면 코드가 어느순간 꼬이기 시작하면 아까워서 못지우고 계속 수정하고 버티다가 밤을 새고, 체력이 망가지고 패가망신하게 된다.
결국 갈아엎게 되느니만 못하다.
이것을 해결하기 위해 소프트웨어 개발 방법론이 나타났는데, 이를 소프트웨어 공학이라고 부르게 된다.
소프트웨어 공학에서 제시하는 소프트웨어 개발 모델은 많지만 가장 오래되고 전통적으로 사용되는 것은 폭포수 모델(waterfall model)이다.
프로젝트 계획 -> 업무 분석 -> 시스템 설계 -> 프로그램 구현 -> 테스트 -> 유지보수
순으로 폭포가 떨어지듯이 각 단계가 끝나면 다음 단계로 진행하는 과정이다.
각 단계가 명확히 구분되어서 프로젝트의 진행단계가 명확해지는 강점이 있으나, 다시 거슬러 올라가기는 어렵다.
구현 보다는 분석과 설계에 집중적으로 해야한다.
데이터베이스 모델링의 개념
데이터베이스 모델링(데이터 모델링) 이란 현 세계에서 사용되는 작업이나 사물들을 DBMS의 데이터베이스 개체로 옮기기 위한 과정이다.
데이터베이스 모델링은 모델링을 하는 사람이 어떤 사람이냐에 따라 각기 다른 결과가 나올 수 밖에 없다. 모델링은 그래서 많은 프로젝트 경험과 데이터베이스 관련 지식이 있는 사람이 담당하는 것이 일반적이다. 이거부터 잘못되면 쓰레기 프로젝트가 됨.
데이터베이스 모델링 실습
개념적 모델링, 논리적 모델링, 물리적 모델링 3단계에 걸쳐서 완성하는 것이 보편적.
액셀에 이런 기본 데이터가 기록되어 있다고 가정하자. 고객은 여러 번 방문할 수도 있고, 방문해서 아무것도 사지 않고 갈 수도 있다.
기록된 내용에서 물건을 구매한 적이 없는 고객을 위쪽으로 다시 정렬해보자.
이러면 L자 모양의 테이블이 완성되었다. L자형 테이블의 문제는 공간이 낭비된다. 구매한 물건 정보 부분이 많이 비어있는데도 그 공간을 사용하지 않기 때문이다.
이 L자형 테이블을 빈칸이 있는 곳과 없는 곳으로 분리해보자. 그러면 방문기록이 곡객테이블과 구매 테이블로 테이블이 분리된다.
분리가 완료되었다. 고객 테이블에서는 똑같은 정보가 중복되어 있기에, 중복을 제외하고 하나만 남기자.
고객테이블 중곡븍 제거하니, 10개가 남았다. 각각의 고객을 구분하기 위해서 고객 이름을 고객을 구분할 수 있는 구분자로 설정하였다. 이를 기본기(PK, Primary Key)라고 한다. 각행을 구분하는 유일한 기본키 이다. 기본 키의 조건은 중복되지 않고 비어있지 않아야 한다.(실제로는 동명이인 때문에 아이디로 구분)'
구매테이블은 누가 구매한 것인지를 알 수 없으므로, 회원의 기본키로 설정된 이름을 넣어주자
이때, 구매 테이블의 고객이름은 중복되었다고 중복을 없애면 안 된다.
최종적으로
왼쪽의 고객테이블과 오른쪽의 구매 테이블이 잘 구분되었다. 이 둘은 밀접한 관련이 있는 테이블이다. 구매 테이블로만으로 고객에게 배송할 수 없기에, 이 두 테이블의 업무적인 연관성을 맺어줘야한다. 이를 관계라고 부른다.
부모 테이블과 자식 테이블로 구분해주자. Master(주) 가 되는쪽은 부모, Detail(상제)가 되는 족은 자식으로 설정할 수 있다.
그래서 고객테이블이 부모, 구매 테이블은 자식이 된다.
사람 한 명이 여러 개의 물건을 구매할 수 있기에, 1대 다(1:N)관계라고 지칭한다. 1대다 관계는 관계형 데이터베이스에서 가장 보편적인 테이블 사이의 관계이다.
여기서 부모 테이블인 고객 테이블과 자식 테이블인 구매 테이블의 관계를 맺어주는 역할은 기본키와 외래키를 설정함으로써 이루어진다. 고객테이블에서 기본키를 고객 이름으로 설정했고, 자식 테이블의 외래키는 부모 테이블의 기본키와 일치하는 구매 테이블의 고객 이름으로 설정해야 한다.
외래키가 갖는 의미는 외래 키를 가지고 부모 테이블로 찾아가면 유일하게 하나의 정보를 얻을 수 있다라는 의미이다.
"서민재" 라는 사람이 모니터 1개 구매하려고 할 때, 구매 테이블에서 서민재, 모니터 등의 행이 추가되어야하는데, 고객 테이블에 서민재가 없으므로 PK, FK 제약조건이 위배되므로 추가할 수 없다(참조 무결성)
또한 김범수가 회원 탈퇴를 할려고 할 때, 자식테이블에 구매한 기록이 있기에 삭제 되지 않는다.
아무튼 이제 만들어진 테이블들을 정리하면
테이블 이름 | 열 이름 | 데이터 형식 | NuLL 허용 | 기타 |
고객 테이블 (userTBL) |
고객 이름(userName) | 문자(최대 3글자) | X | PK |
출생년도(birthYear) | 숫자(정수) | X | ||
주소(addr) | 문자(최대 2글자) | X | ||
연락처(mobile) | 문자(최대 12글자) | O | ||
구매 테이블 (buy TBL) |
고객 이름(userName) | 문자(최대 3글자) | X | FK |
구매한 물건(prodName) | 문자(최대 3글자) | X | ||
단가(price) | 숫자(정수) | X | ||
수량(amount) | 숫자(정수) | X |
이렇게 설계가 완료되었고, 두 개의 테이블과 각각의 테이블에는 4개의 열이 정의되었다.
NULL 허용은 연락처에만 없는 데이터가 있을 수 있다.
Workbench 로 모델링하기
왼쪽 위에 File -> New Model 버튼을 누르면
mydb에서 Edit Schema 버튼을 누르면
뭔가 설정할 수 있는 창이 뜬다.
이름을 modelDB로 설정하고 스키마 창을 닫는다.
Add Diagram 버튼을 누르면
EER Doagram 탭이 추가되고 다이어그램을 그릴 수 있는 상태가 된다.
그 다음 Place a New Table 아이콘을 클릭하고 빈 화면에 마우스 클릭하면 테이블이 생성된다.
T 버튼을 눌러도 되는 것 같다.
더블클릭하고 밑에 표 채우면 위와 같이 자동적으로 다이어그램이 완성된다.
똑같이 구매테이블도 완성해주자
이렇게 이름까지 싹 바꾸고 완성이 되었다.
그 다음 왼쪽 아래에 1:N버튼을 클릭하고 buyTBL, userTBL을 각각 userNAme 버튼을 누르면
이렇게 연결이 된다.
1:N관계가 성립이 된 것이다.
file->Save Model 을 누르거나 ctrl+s를 눌러서 modelDB.mwb 로 입력하고 저장한다.
이러면 모델링 완료
모델링 파일을 실제 데이터베이스에 적용시켜보기
file -> open Model 을 클릭하고
아까 저장한 ModelDB.mwb를 불러들인다
아까 그창이다.
Workbench 메뉴의 [Database] >> [Forward Engineer]를 선택한다.
이 창이 나오면 Local Instance MySQL을 선택하고 Next 를 누른다.
그냥 Next
비번 입력하고 ok
Export MySQL Table Objects 누르고 Next를 누른다
Next
이러면 완료
refresh all 누르면 modeldb가 생성되어있는 것을 확인할 수 있다.
기존에 존재하는 데이터베이스를 이용해서 다이어 그램 작성하기
이제 거의다 왔다.
[Database] >> [Reverse Engineer] 를 선택하고
계속 NEXT를 누르다보면
여기서 작업하고 싶은 거 클릭
전부 체크되어있는지 확인하고 Execute 누른다
완성
잘 나왔다. 이제 이걸 shopDB.mwb로 저장한다
이상 간단한 데이터베이스 모델링이다. 힘들다...
에필로그
이 부분은 데이터베이스 모델링 부분으로 잘하는 사람은 드물다고 한다;
확실히 좀 빡세긴 한데 해볼만할지도...?
'데이터베이스' 카테고리의 다른 글
[데이터베이스] 데이터베이스 백업 및 관리 #8 (0) | 2024.01.28 |
---|---|
[데이터베이스] 데이터베이스 개체의 활용 - 트리거 #7 (0) | 2024.01.20 |
[데이터베이스] 데이터베이스 개체의 활용 - 스토어드 프로시저 #6 (0) | 2024.01.20 |
[데이터베이스] 데이터베이스 개체의 활용 - 뷰 #5 (0) | 2024.01.20 |
[데이터베이스] 데이터베이스 개체의 활용 - 인덱스 #4 (0) | 2024.01.20 |