프로젝트 이름은 EduClass로 붙였다.
일단 이 서비스 자체가 대학생들이 사용하는 온라인 클래스와 비슷해서 그렇게 부르게 되었다.
EduClass를 시작할 데이터베이스를 정리했다. 처음에는 Entity를 구성할 때 좀 막막했던 것 같다. 일단 pk, fk의 개념이 확실히 와닿지 않다보니 중복해서 넣는 속성들이 많아지니 복잡해졌다.
예를 들어보자.
처음에는 user의 분류를 3개로 나눴다. '학생', '학부모', '관리자'
'학생'은 강의를 듣고 시험을 보는 user.
'학부모'는 본인의 학생의 강의 수강 상황과 시험 점수를 열람할 수 있는 user
'관리자'는 학생과 학부모의 정보를 관리하고 문제와 강의를 편집할 수 있는 user
각각의 email과 pw를 속성으로 만들었다. 그럴 경우 로그인을 할 때 email과 pw가 맞는 user 테이블을 찾기위해 3개의 테이블을 검색해야 한다는 복잡함이 생기게 되었다. 그래서 인증/인가 entity를 통해 분리하게 되었다.
왜 인증/인가 엔터티를 분리할까?
- 보안성 강화:
- 이메일과 비밀번호는 민감한 정보이므로, 이를 별도로 관리하면 데이터 보호 및 보안 강화에 유리하다.
- 공통 데이터 관리:
- 학생, 학부모, 관리자 모두 로그인 정보를 공통적으로 사용하므로 이를 한곳에 통합해 관리하는 것이 효율적이다.
- 확장성:
- 향후 새로운 사용자 유형(예: 강사, 조교 등)이 추가될 경우, 인증/인가 엔터티에만 추가하면 됩니다.
- 역할(Role) 기반 권한 관리(RBAC: Role-Based Access Control)를 구현하기 쉽다.
- 데이터 중복 방지:
- 사용자 entity마다 emaiil 비밀번호를 따로 관리하면 데이터 중복 및 비효율성이 발생합니다. 이를 인증 Entity로 통합하면 해결된다.
변수명 id? student_id?
처음에는 '학생'의 변수명은 모두 'student_id', 'student_pw' 이런식으로 앞에 클래스이름을 붙였다. 근데 생각해보니 class 변수를 가져올 때, 'student.student_id' 라고 쓰지는 않는다는 사실을 깨닫고 다 지웠다.
'EduClass Project' 카테고리의 다른 글
[Project] N:M 매핑에서 복합 키(Composite Key)를 사용할 때 주의할 점 (0) | 2025.03.05 |
---|---|
[Project] 불필요한 Entity 제거를 통한 데이터베이스 설계 최적화 – Test Entity를 없앤 이유 (0) | 2025.03.05 |
[Project] (4) API 구현(@RequestParam vs @PathVariable) (0) | 2025.02.07 |
[Project] (3) 프로젝트 시작(MVC 패턴, 디렉토리 구조) (1) | 2025.02.05 |
[Project] (1) 프로젝트 시작(플로우차트, Entity 설계) (1) | 2025.01.23 |