지난번에는 낙관적 락을 이용해서 문제 해결을 해보았다.

이번에는 비관적 락을 이용해보자 비관적 락의 단점에 대해서는 해당 링크에서 확인했었는데, 우리 프로젝트는 팀에 가입하고 업무를 부여받는 식이기 때문에 충돌할 가능성이 낮다고 판단했고 낙관적 락을 사용했었다.

동시성 처리 전

해당 Test코드는 낙관적 락을 적용하기 전과 같다. 100명을 가입신청 한다.

    @Test
    @DisplayName("5명 제한 팀에 100명이 동시에 가입 신청")
    void joinTeamTest()throws InterruptedException{
        //given
        final int JOIN_USER = 100;
        User user1 = createUser();
        createTeam(user1.getId());
        TeamJoinDto joinDto = TeamJoinDto.builder()
                .joinCode("1111")
                .build();
        CountDownLatch countDownLatch = new CountDownLatch(JOIN_USER);
        //101명을 한번에 넣어주기 위함
        ExecutorService executorService = Executors.newFixedThreadPool(101);

        //when
        for (int i = 0; i < JOIN_USER; i++) {
            User user2 = createUser();
            executorService.submit(()->{
                try{
                    teamService.joinTeam(user2.getId(),joinDto,1L);
                } finally {
                    countDownLatch.countDown();
                }
            });
        }
        // 모든 작업이 완료될 때까지 대기
        countDownLatch.await();

        // then
        // 5명이어야한다.
        List<MemberEntity> members = memberRepository.findAll();
        System.out.println(members.size());
        assertThat(members.size()).isEqualTo(5);
    }

결과

5명 정원인데, 30명이 가입되었다.

동시성 처리

JPA의 @Lock을 이용했다. TeamReposiotry에서 @Lock(LockModeType.PESSIMISTIC_WRITE)을 통해 쿼리에 비관적 잠금을 적용한다. 이렇게 되면 해당 엔티티에 대해 다른 트랜잭션이 쓰기 잠금을 걸 수 없다.

@Repository
public interface TeamReposiotry extends JpaRepository<TeamEntity, Long> {
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("select t " +
            "from TeamEntity t " +
            "where t.id =:teamId")
    Optional<TeamEntity> findByIdWithPessimisticLock(@Param("teamId") Long teamId);
}

현재는 팀을 조회하고 5명이 넘었는지 확인하는 과정에 있다. 따라서 JPQL을 위처럼 작성했다. 이제 joinTeam 메서드에서 팀을 조회할 때 findByIdWithPessimisticLock 를 사용한다. 팀을 조회할 때 기존의 findById를 주석처리

결과

다섯명이 정상적으로 가입되었다.다음 시간에는 분산락을 알아보고, 적용해보는 시간을 가지려 한다. 그리고 여태 적용해봤던 락들이 실제 실행시간을 비교해보겠다.

이게 무슨 일인가 싶다.. 나는 정처기 1회 필기를 합격했었다.

맞다. 학력증명서를 내지 않아서 합격이 취소되었다..... 그래서 실기를 보지 못하고 필기를 다시 봤다😢

다들 시험 결과가 발표되면 대략 열흘 이내 응시자격 서류제출을 꼭 하길 바란다.. 고객지원 공지사항에 가보면 일정이 있다. 기사 시험은 밑에 1회, 2회, 3회로 구분 지어 나와 있다. 온라인 제출을 하지 않으면 서류제출기간 내에 직접 공단에 방문하거나, 우편으로 보내야 하는 것으로 안다. 본인은 실기접수를 하려고 보니깐, 이미 서류제출기간이 지나있었다.. 전화까지 해봤는데 기간 지나면 절대 안 받아줍니다.. 주의하세요!

그렇게 온라인 접수를 하는데, 학력증명서는 사본제출이 안 돼서 여기서 직접 결제하고 제출했다 .내돈 2,500원..제출완료 되면 바로 승인되지는 않는 모양이다..당장은 아무것도 뜨지 않는다. 이게 제출이 된 것인지, 또 기한 내에 못내는 건 아닌지 걱정이 됐다.. 그리고 이틀이 지난 후 승인이 완료됐다. 이제 안심이 된다..😂 자격증 하나도 못 따는 양상이 될까 걱정했는데 다행히 그때 같이 준비했던 SQLD가 합격했다.지금부터라도 잘 확인하고 차곡차곡 역량을 쌓아나가야겠다..

지난 시간에 동시성 제어와 데드락에 대해서 알아봤다. 이번에는 프로젝트에 동시성 처리를 적용해본다.

대략 서비스를 설명하자면, 먼저 회원 가입을 하고 팀에 가입한다. 팀에 가입하기 위해서는 Join코드가 필요하고 '1111' 로 세팅했다.

팀 인원이 5명 제한이 걸려있는데, 100명을 동시에 가입시켜보려 한다.

동시성 처리 전 Code

    @Test
    @DisplayName("5명 제한 팀에 100명이 동시에 가입 신청")
    void joinTeamTest()throws InterruptedException{
        //given
        final int JOIN_USER = 100;
        User user1 = createUser();
        createTeam(user1.getId());
        TeamJoinDto joinDto = TeamJoinDto.builder()
                .joinCode("1111")
                .build();
        CountDownLatch countDownLatch = new CountDownLatch(JOIN_USER);
        //101명을 한번에 넣어주기 위함
        ExecutorService executorService = Executors.newFixedThreadPool(101);

        //when
        for (int i = 0; i < JOIN_USER; i++) {
            User user2 = createUser();
            executorService.submit(()->{
                try{
                    teamService.joinTeam(user2.getId(),joinDto,1L);
                } finally {
                    countDownLatch.countDown();
                }
            });
        }
        // 모든 작업이 완료될 때까지 대기
        countDownLatch.await();

        // then
        // 5명이어야한다.
        List<MemberEntity> members = memberRepository.findAll();
        System.out.println(members.size());
        assertThat(members.size()).isEqualTo(5);
    }

결과

5명은커녕 29명이 가입된 것을 알 수 있다. 제작한 프로젝트는 팀의 인원수를 제한하고 인원수 증설에 따른 결제를 필요로하게했지만, 이런 오류가 발생하면 치명적일 수 있다. 앞서 배운 동시성 제어가 필요해보인다.

이런 오류가 이커머스나 선착순 타임세일 같은 긴박한 프로젝트였을 경우 문제는 더 커지겠지만, 우리 프로젝트는 그저 팀에 가입하고 업무를 부여받는 식이기 때문에 충돌할 가능성이 낮다고 판단했고 낙관적 락을 사용해보기로 했다.

동시성 처리

낙관적 락 개념은 지난 시간에 학습했다. 낙관적 락은 JPA에서 지원해주기에 구현이 간단하다. 먼저 아래를 Entity에 추가한다. 팀에 가입하는 단계에 버전을 조회해야 한다. 즉, joinTeam 메소드를 수정해야 한다.

테스트 코드에서는 변한 게 없다. 테스트 코드에서 체크한 부분의 joinTeam메서드가 수정되어야 한다. 팀을 조회할 때 findById를 주석처리하고 findByIdWithOptimisticLock 를 사용했다.

findByIdWithOptimisticLock는 TeamReposiotry에서 아래처럼 간단하게 작성한다.

@Repository
public interface TeamReposiotry extends JpaRepository<TeamEntity, Long> {
    @Lock(value = LockModeType.OPTIMISTIC)
    @Query("select t " +
            "from TeamEntity t " +
            "where t.id =:teamId")
    Optional<TeamEntity> findByIdWithOptimisticLock(@Param("teamId") Long teamId);

현재는 팀을 조회하고 5명이 넘었는지 확인하는 과정에 있다. 따라서 JPQL을 위처럼 작성했다.

결과

정상적으로 5명이 가입된 것을 알 수 있다. 다음 시간에는 비관적 락을 사용해서 처리해본다.

첫 문제접근

나올 수 있는 점수를 모두 생각했다. 이 문제의 경우에는 1~20 그리고 2의 배수들, 3의 배수들, 50이 있다. 해당 점수들로 target을 만들 수 있는 조합은 굉장히 많다. 거기서 가장 적은 수로 조합하고, 조합한 화살의 개수가 같다면 Single이나 50점을 많이 쓴 경우를 출력한다.

만약 이마저도 같다면, 먼저 던진 선수가 승리한다는데, 이 조건은 필요 없다. 어차피 우리가 구해야 하는 것은 가장 적은 개수의 조합으로 target을 완성했을 때 single과 50점을 몇 개나 맞췄는지를 구하는 것이다.

시간복잡도

• 1 ≤ target ≤ 100,000

최대 Nlog(N)의 시간복잡도로 접근해야 한다. 해당 문제는 target을 달성해도 또 조건이 있기 때문에 greedy로는 풀 수 없다. 최선의 경우의 수가 target이 변할 때마다 최적의 조건으로 변하기 때문에 DP를 생각해 볼 수 있다. 그러나 나는 여기까지 밖에 생각을 못했다. 구현하기가 너무나 어려웠음. 다른 풀이를 참고했다.

문제 풀이

1. DP를 이용해서 역순으로 target을 줄여가며 0이 될 때까지 최적의 경우를 찾아간다.
2. 50점이 가능한 경우, Single이 가능한 경우, 두 배, 세 배 점수를 맞춰서 가능한 경우를 나눈다. 2-1. 50점과 Single을 최대한 써야 하기 때문에 if를 앞단에 배치한다.
3. 50점 또는 Single이 더 많은 경우 DP값을 갱신한다.

아래 주석으로 설명하겠다.

def solution(target):
    answer = []

    # 이렇게 쓴 이유는 아래 설명
    dp = [[target-i, target-i] for i in range(target+1)]

    # 목표 점수에서 0점까지 역순으로 탐색
    for i in range(target, -1, -1):
        # 1점부터 20점까지 점수를 고려
        for j in range(20, 0, -1):

            # 50점을 쏠 수 있는 경우
            if i-50 >= 0:
                # 50점을 쐈을 때 화살 개수가 더 적다면 갱신
                if dp[i-50][0] > dp[i][0]+1:
                    dp[i-50] = [dp[i][0]+1, dp[i][1]+1]

                # 더 많이 쏜 불 또는 싱글 수로 갱신
                elif dp[i-50][0] == dp[i][0]+1 and dp[i-50][1] < dp[i][1]+1:
                    dp[i-50] = [dp[i][0]+1, dp[i][1]+1]

            # 싱글을 쏠 수 있는 경우
            if i-j >= 0:
                # 더 적은 화살 수로 갱신
                if dp[i-j][0] > dp[i][0]+1:
                    dp[i-j] = [dp[i][0]+1, dp[i][1]+1]

                # 더 많이 쏜 불 또는 싱글 수로 갱신
                elif dp[i-j][0] == dp[i][0]+1 and dp[i-j][1] < dp[i][1]+1:
                    dp[i-j] = [dp[i][0]+1, dp[i][1]+1]
            else:
                # 남은 점수가 단일 점수보다 작으면 더 이상 진행하지 않음
                break

            # 더블 을 쏠 수 있는 경우
            if i-2*j >= 0:
                # 더 적게 쏴서 도달할 수 있을 때
                if dp[i-2*j][0] > dp[i][0]+1:
                    dp[i-2*j] = [dp[i][0]+1, dp[i][1]]

                # 같은 수를 쐇지만, 불 또는 싱글을 더 많이 맞출때
                elif dp[i-2*j][0] == dp[i][0]+1 and dp[i-2*j][1] < dp[i][1]:
                    dp[i-2*j] = [dp[i][0]+1, dp[i][1]]

            # 트리플 을 쏠 수 있는 경우
            if i-3*j >= 0:
                # 더 적게 쏴서 도달할 수 있을 때
                if dp[i-3*j][0] > dp[i][0]+1:
                    dp[i-3*j] = [dp[i][0]+1, dp[i][1]]

                # 같은 수를 쐇지만, 불 또는 싱글을 더 많이 맞출때
                elif dp[i-3*j][0] == dp[i][0]+1 and dp[i-3*j][1] < dp[i][1]:
                    dp[i-3*j] = [dp[i][0]+1, dp[i][1]]

    # 목표 점수에 도달하기 위한 최소 화살 수와 최대 불 또는 싱글 수 반환
    return dp[0]

코드해석

본인은 저 코드만 보고 이해하기 어려웠다.. 좀 더 해석을 덧붙이겠다.

dp = [[target-i, target-i] for i in range(target+1)] 이렇게 작성한 이유는 DP를 뒤에서부터 진행하기 때문이다.

dp[i]의 인덱스 i는 현재 점수를 나타낸다. 예를 들어 dp[100]은 목표 점수 100에 도달하는 경우를 나타내고, dp[50]은 목표 점수 50에 도달하는 경우를 나타낸다.

target이 100이라면

# dp[100] = [0, 0]  # 100점에 도달하기 위한 초기값 (화살 0개, 싱글 0개)
# dp[99] = [1, 1]   # 99점에 도달하기 위한 초기값 (화살 1개, 싱글 1개)
# dp[98] = [2, 2]   # 98점에 도달하기 위한 초기값 (화살 2개, 싱글 2개)

자 여기까지 이해됐다면, 아래 코드까지만 해석해보겠다. 아래가 이해된다면 모든 게 끝

 for i in range(target, -1, -1):
        # 1점부터 20점까지 점수를 고려
        for j in range(20, 0, -1):

            # 50점을 쏠 수 있는 경우
            if i-50 >= 0:
                # 50점을 쐈을 때 화살 개수가 더 적다면 갱신
                if dp[i-50][0] > dp[i][0]+1:
                    dp[i-50] = [dp[i][0]+1, dp[i][1]+1]

                # 더 많이 쏜 불 또는 싱글 수로 갱신
                elif dp[i-50][0] == dp[i][0]+1 and dp[i-50][1] < dp[i][1]+1:
                    dp[i-50] = [dp[i][0]+1, dp[i][1]+1]

여기서

if dp[i-50][0] > dp[i][0]+1:
    dp[i-50] = [dp[i][0]+1, dp[i][1]+1]

이부분이 이해가 잘 안됐다. 여기서 주의해야 할 점은 dp[i-50][0]이 50점을 쐈을 때 화살의 개수가 아니다. dp[i][0]+1이 50점을 쐈을 때 화살의 개수이다.

i가 100일 때를 생각해보자 dp[50][0] > dp[100][0]+1 을 비교하게 된다. 처음 dp[50][0] = 50으로 세팅되었고, d[100][0] = 0이다. 그러니 50점을 맞췄다고 가정했을 때 화살의 개수는 d[100][0] + 1 이 된다. 이것은 1이고 dp[50][0]보다 작으니 dp[i-50] = [dp[i][0]+1, dp[i][1]+1] 처럼 갱신한다.

아래 코드들도 그런 식이다. .

후기

솔직히 처음에 코드를 보고 이해가 어려웠다. 어떻게든 이해해보고 싶었는데, 설명할 수 있다면 이해했다고 할 수 있지 않을까 싶어 작성했다. 한 명이라도 도움이 되었다면 좋겠다.

데드락이란 ?

교착 상태(膠着狀態) 또는 데드락(영어: deadlock)은 두 개 이상의 작업이 서로 상대방의 작업이 끝나기 만을 기다리고 있기 때문에 결과적으로 아무것도 완료되지 못하는 상태

쉽게 그림을 이용해 설명하겠다.

회사에서 코딩테스트를 치뤘다. 총 두 문제가 출제되었고, 이 회사에 합격하려면 두 문제를 모두 맞춰야 한다.

A는 1번 문제의 정답 코드를 알고 있다. B는 2번 문제의 정답 코드를 알고 있다. 상대가 답안 제출을 끝내고 퇴실하면, 상대가 쓴 코드를 몰래 볼 수 있다.

당신 같으면 먼저 갈 것인가? 아마 서로 먼저 가길 눈치만 보다가 시험이 종료되고 집에 가서 울게 될 것이다.

그럼 이게 왜 발생하는데 ? 를 생각해 볼 수 있다. 데드락의 발생조건은 네 가지가 있다. 이 네 가지가 모두 만족되어야 데드락이 발생한다.

데드락의 필요조건 4가지

• 비선점 이미 할당된 자원을 강제로 빼앗을 수 없다. 상대의 답안지를 강제로 뺏을 수 없던 것처럼 말이다.
• 점유와 대기 다른 프로세스에 할당된 자원을 점유하기 위해 대기해야 한다. 상대의 답안지를 보기 위해 다 쓰고 제출할 때까지 기다려야 했다.
• 순환 대기 대기 프로세스의 집합이 순환 형태로 자원을 대기한다. A는 B의 답안을 기다리고, B는 A의 답안을 기다리는 형태이다.
• 상호 배제 자원은 한 번에 한 프로세스만 사용할 수 있다. 위 예시에서는 한 명이 하나의 답안만 아는 상황을 가정했다.

데드락 해결 방안

그렇다면 데드락 조건의 4가지를 어기면 되는 거 아닌가? 를 생각해 볼 수 있다. 이 방식은 교착 상태 예방에 해당하는 방법이고, 데드락 해결 방안은 크게 4가지가 있다.

• 교착 상태 예방 필요조건을 거부하는 방법

1. 비선점 조건을 거부 - 프로세스가 강제로 자원을 잃을 수 있어, 작업의 일관성이 깨질 수 있다.
2. 점유와 대기 조건을 거부 - 모든 자원을 한꺼번에 요청하면 다른 프로세스가 자원을 얻기 어려워져서 자원의 효율적인 사용이 어려워진다.
3. 상호 배제 조건 거부 - 자원을 여러 프로세스가 동시에 사용할 수 있게 되는데, 이는 실제로 불가능하거나, 데이터의 무결성을 해칠 수 있다.
4. 순환 대기 조건 거부 - 자원의 순서를 정하는 데 복잡성이 증가하고, 순서에 따라 요청이 제한되어 비효율적일 수 있다.

결론적으로 자원 사용 효율성이 떨어지고 비용이 많이 드는 단점이 있기에 실제로 잘 사용되지 않는다.

• 교착 상태 회피 데드락이 발생할 위험이 있으면 진작에 회피하여 방지하는 방법 자원 할당시, 교착 상태로부터 안전한 경우에만 자원을 할당함으로써 예방한다. 여기서는 주로 은행원 알고리즘을 사용한다.

  시스템 자원의 사용을 최적화할 수 있지만, 자원을 요청할 때마다 계산을 해야 하므로 복잡도가 높고, 얼마의 자원을 필요로 하는지 알아야 하는데 동적 자원환경에서 유연성이 떨어진다.

• 교착 상태 탐지 및 회복 교착 상태가 발생할 가능성을 허용하고, 교착 상태가 발생하면 이를 탐지하고 회복하는 방법

• 탐지 *방법으로는 자원 할당 그래프를 통해 순환 사이클의 존재를 확인한다. 순환 사이클의 존재를 교착 상태 발생으로 간주한다. 그렇게 주기적으로 자원의 상태와 프로세스의 상태를 검사하여 교착 상태가 발생했는지 확인

  단점으로 자원의 상태를 지속적으로 모니터링해야하기 때문에 오버헤드가 커질 수 있다.

  회복으로는 교착 상태에 있는 프로세스 중 일부를 종료하여 자원을 해제하는 방법이 있다. 이때 먼저 종료할 프로세스의 우선순위를 두어 자원을 잃을 수 있는 단점을 최소화한다.

  또한 자원을 선점하는 방식이 있다. 특정 프로세스에서 자원을 강제로 회수하여 다른 프로세스에 할당한다. 이때는 기아상태를 조심해야 한다. 매번 자원을 회수 당하기만 해서 처리가 되지 않는 상태가 발생할 수 있다.

교착 상태가 자주 발생하는 곳에서 사용되며, 실제로 가장 많이 사용되는 기법이다.

• 교착 상태 무시 교착 상태를 해결하는 것은 비용 문제를 일으킨다고 판단하고 특별한 방법을 사용하지 않는다. 만약 교착 상태 발생시에는 시스템을 재부팅 시키는 방식으로 해결 교착 상태가 자주 발생하지 않는 시스템에서 사용된다.

이렇게 데드락에 대해서 알아보았다. 👋개념 정리를 했으니 다음에는 MySQL을 사용한 프로젝트에 적용한 것을 소개하겠다.👋

동시성 제어에는 Lock을 사용한 방법이 있다. 이번 시간에는 낙관적 락과 비관적 락에 대해서 알아본다.

낙관적 Lock

충돌하지 않을 것이라고 보고 진행한다. 그렇다면 어떻게 충돌을 방지할까?

방식

버전(Version)을 사용한다. 해당 데이터의 버전을 읽고, 데이터를 Commit하기 전에도 다시 버전을 읽는다. 이 두 버전이 일치할 때 비로소 Commit을 한다.

대략적 이미지는 아래와 같다.

이렇게 하면, 누군가가 동시에 데이터를 수정했을 때 먼저 수정한 사람의 Commit으로 인해 버전이 변경된다. 따라서 두 번째로 데이터를 수정하려는 사람은 처음 읽었을 때의 버전과 Commit 전에 읽은 버전이 달라진 것을 확인하고, 충돌이 발생할 뻔했다는 것을 인지하게 되어 롤백을 한다.

낙관적 락을 쓰는 경우

• 충돌 가능성이 낮은 경우 - 데이터 수정이 드문 시스템에서 효과적이다. (읽는 작업이 많은 경우 ex 게시판)
• 성능이 중요한 경우 - 충돌이 발생하지 않는다는 가정하에 트랜잭션을 유지할 필요가 없어 성능이 비관적 락보다 좋다.
• 비동기 처리를 할 경우 예를 들면 영화 티켓을 예매한다고 생각해보자.

1. 클라이언트는 서버에 잔여석 정보를 요청한다.
2. 클라이언트는 잔여석 정보를 받고, 정보를 입력하며 결제 준비를 한다. 이후 결제 요청
3. 서버는 처음 버전과 결제 요청시 버전을 확인하기만 하면 된다. => 클라이언트가 데이터를 받고 수정 후 재전송 할 때까지 트랜잭션을 유지할 필요도 없고, 비동기적으로 처리할 수 있다. 이는 데드락을 피하는 데 유리하다.

낙관적 락의 단점

• 실패시 롤백 처리가 복잡도가 올라간다.
• 충돌이 일어난 경우 재시도를 해야 한다. 수정이 빈번하게 일어나는 시스템에서는 계속 버전이 변경될 수 있어, 재시도가 반복될 수 있다.

비관적 Lock

충돌할 걸 예상하고 락을 걸어서 진행하는 방식이다. 락을 걸고 데이터를 수정하는 동안, 다른 사용자는 자원을 이용할 수 없기에 대기를해야 한다.

여기에는 배타락(Exclusive lock)과 공유락(Shared lock)이 있다.

1. 배타 Lock

흔하게 생각해 볼 수 있는 방식으로, 한 트랜잭션이 진행되는동안 다른 트랜잭션이 접근을 못하게 Lock을 걸어둔다. 이는 전용 lock이라고도 하며, Lock이 걸리는 순간 다른 트랜잭션의 읽기와 쓰기는 불가능하다. Commit이 끝난 뒤 Lock이 풀리면 다음 트랜잭션이 권한을 가져간다.

2. 공용 Lock

read연산은 가능하고 write연산은 불가능 하게 끔 한다. 한 트랜잭션이 공유 락을 걸면 다른 트랜잭션도 동일한 데이터에 공유 락을 걸 수 있지만, 배타 락은 걸 수 없다.

우리가 여기서 알아야 할 점은** 로킹 단위(Loking Granularity)**이다.

로킹 단위(Loking Granularity)

즉 어떤 범위로 묶어서 Lock을 걸 것이냐 ? 라는 의미인데

크다 --------------------------------> 작다 데이터베이스, 릴레이션, 튜플, 속성 단위로 가능하다.

로킹 단위가 커질수록 구현이 쉽고 (그냥 대충 한번에 묶어버리면 되니깐_) 병행성 수준이 낮아진다. 때문에 로킹 오버헤드 감소

로킹 단위가 작아지면 병행성 수준이 높아져 여러 트랜잭션이 동시에 진행될 수 있지만, 관리가 어렵고 락 오버헤드가 증가

이렇게 종류를 알아보았다. 그렇다면 언제 낙관을 쓰고 언제 비관을 쓰는가?

비관적 락을 쓰는 경우

• 수정하는 일이 빈번한 경우 - 낙관적 락의 단점을 처리할 수 있다.
• 실시간으로 데이터를 처리해야 하는 시스템에서 사용
• 데이터 무결성이 매우 중요한 경우 - 갱신 손실(Lost Update) 문제를 해결하여 데이터의 정합성을 유지한다.

비관적 락의 단점

• 동시에 접근하는 트랜잭션이 많아지면 대기 시간이 늘어나고, 시스템 성능이 저하된다.
• 락이 걸려 있는 동안 다른 트랜잭션이 대기해야 하므로 병행성이 떨어진다.

👋다음 시간에는 이로 인해 발생하는 데드락이 무엇인지 알아본다.👋

첫 문제접근

시간복잡도

• 2 ≤ n ≤ 100,000

이정도의 시간 복잡도에서는 이중반복문을 사용하면 안 된다는 생각이 들었다. 그래서 내가 생각한 풀이는 딕셔너리를 사용하여 연결을 나타냈다.

여기서 leaf 노드란 자식 노드가 없는 노드를 말한다.

💥 그러나.. 놓쳤던 점, 주의해야 할 점❗

내가 문제를 잘 못 이해했었다.. 위처럼 하게 되면이게 성립되는데, 이 그림에서 배는 지나갈 수가 없다. 3과 4 그리고 6과 7이 끊어져 있는 상태이기 때문이다. 이 그림은 아래처럼 변해야 한다.이게 문제에서 말하는 것이었다. 최소, 하나 걸러 하나는 켜져 있어야 한다.

문제 풀이

1. 딕셔너리를 이용해 연결 정보를 넣어둔다.
2. DFS를 이용해서 현재 노드가 켜졌을 때와 꺼졌을 때 두 개의 값을 반환한다.

아래 주석으로 설명하겠다.

from collections import defaultdict
import sys
sys.setrecursionlimit(1000001)

visited = [False] * 1000001 
nodes = defaultdict(list) # 기본값이 빈 리스트인 딕셔너리

def dfs(now):
    visited[now] = True  # 현재 노드 방문처리
    if nodes[now]==[]: # 본인이 leaf(자식 노드가 없는 노드)라면
        return 1, 0 #본인이 켜졌을 때와 꺼졌을 때 두 개의 값 반환

    # leaf가 아니라면 (자식 노드가 하나 이상 있는 경우)
    on, off = 1, 0  # 시작 값을 켰을 때와 껐을 때, 두 개로 나눠서 출발

    for nd in nodes[now]: # 자식 노드를 둘러본다
        if not visited[nd]:
        # 자식 노드 nd를 켰을 때와 껐을 때의 최소 점등 등대 개수
          child_on, child_off = dfs(nd) 

          # 내가 켜졌다면 자식 노드들은 켜지든 꺼지든 상관 없음 
                  #-> 자식 노드가 켜진 경우와 꺼진 경우 중 최소값을 더함
          on += min(child_on, child_off)

          # 내가 꺼졌다면 자식 노드들은 무조건 켜져야 함 
                  #-> 자식 노드가 켜진 경우의 값을 더함
          off += child_on

    return on, off  # 현재 노드를 켰을 때와 껐을 때의 최소 점등 등대 개수를 반환

def solution(n, lighthouse):
    for a, b in lighthouse:
        #연결 정보 생성
        nodes[a].append(b)
        nodes[b].append(a)

    on, off = dfs(1)  # 1번 노드에서 DFS를 시작
    return min(on, off)  # 켰을 때와 껐을 때의 최소 점등 등대 개수 중 작은 값을 반환

알게 된 것

딕셔너리 초반에 항상 아래처럼 선언하고 get( )을 사용하여 빈 값의 키를 넣어주곤 했다.

    dict={}
    for a,b in lighthouse:
        if not dict.get(a):
            dict[a]=0
        if not dict.get(b):
            dict[b]=0
        dict[a]+=1
        dict[b]+=1

defaultdict(list)를 이용해서 바로 빈 리스트의 값을 넣어줄 수 있다는 것을 알게 되었다. 좀 더 깔끔한 코드 구현이 가능할 것 같다.

동시성 제어란?

동시에 실행되는 여러 개의 트랜잭션이 작업을 성공적으로 마칠 수 있도록 트랜잭션의 실행 순서를 제어하는 기법

의미가 잘 와 닿지 않는다. 배경을 알아보자

배경

예시를 들어본다. 만약 영화 표를 예약한다고 생각해보자. 자리가 1개가 남았다. 그런데 만약 여러 명이 동시에 해당 자리를 예약한다면 어떤 현상이 일어날까? 당연히 가장 먼저 예매한 사람이 K24 번 자리를 갖게 될 것이다. 그러나 컴퓨터 시스템에서는 그렇지 않을 수 있다. 우리는 데이터를 변경하고 저장할 때 DB에 자료를 읽어와 수정하고 Commit 과정을 거치게 된다. 쉽게 말해, A가 데이터를 읽어오는 과정에서는 자리가 있었는데, 그 사이에 누군가가 예약한 줄도 모르고 예약이 진행된다면 영화관에서는 싸움이 일어날 것이다.

이제 다시 동시성 제어의 의미를 살펴보면 이해가 간다. 트랜잭션들이 동시에 수행될 때 -> 여러명이 동시에 예약할 때 일관성을 해치지 않도록 -> 여러 예약이 동시에 발생해서 일관성이 해쳐지지 않도록 트랜잭션의 실행 순서를 제어 -> 데이터 접근을 제어하여 충돌을 방지

이렇게 동시성 제어를 하지 않았을 때 생기는 일례를 들었다.

동시성 제어를 하지 않았을 때 문제점

굳이 구분하자면 크게 4가지가 있다. 이것도 너무 복잡해 보인다.. 예시로 설명해 본다.

갱신 손실이 위의 영화관 예시이다. 자리가 예매되어 잔여석 = 0인 데이터가 갱신되기 전에, 두 트랜잭션이 동시에 잔여석 = 1을 읽고 수행하여 생긴 문제이다.

현황파악 오류는 A가 아직 예약을 완료하진 않았는데, 중간 데이터를 읽어온 B는 잔여석 = 0으로 판단하여 생기는 오류이다. A가 아직 Commit을 하지 않아서 Rollback을 하게 되어도, B는 진작에 포기해서 예약을 하지 않을 것이다. 이는 잘 일어나지 않는 오류라고 한다.

모순성 A가 한 좌석을 2만 원으로 예약한다. 그런데 결제 과정에서 영화관이 영화 값을 반값으로 할인하여 데이터를 처리한다고 가정한다. 이 경우 영화관의 데이터베이스에는 1명 * 10,000원으로 계산하여 1만 원의 수입이 기록된다. 그러나 실제로 A가 2만 원을 지불했기 때문에, 계좌를 확인하면 2만 원이 입금된 것을 확인할 수 있다.

이러한 상황에서 영화관의 데이터베이스는 실제 수입과 기록된 수입이 일치하지 않는 모순된 상태가 된다.

연쇄복귀 A사가 5천만 원을 주고 영화관을 통째로 대관했다. 기분이 좋은 영화관은 일주일 전부터 A사 직원들에게 팝콘과 음료 50% 이벤트를 진행했다. 그런데 A사가 코로나 발생을 이유로 계약을 파기(Rollback 요청)했다. 이렇게 되면 영화관도 이벤트를 철회해야 하고, 이를 통해 할인을 받은 고객들에게는 추가 요금을 청구할 수도 있다. 이는 굉장히 까다롭기도 하고 실제로 불가능할지도 모른다.

이처럼 Rollback 과정에서 이미 Commit 된 것이 있다면 회복 불능이 발생할 수도 있다.

👋 다음시간에는 동시성 제어 기법이 무엇이 있는지를 파악해 본다.👋

문제접근

가장 먼저 생각해 볼 수 있는 방법은, 배열을 돌면서 무적권을 쓸지 정면 돌파를 할지 경우의 수를 나누는 방법이다. 이를 위해서 고민할 것은 시간복잡도..

• 1 ≤ n ≤ 1,000,000,000
• 1 ≤ k ≤ 500,000
• 1 ≤ enemy의 길이 ≤ 1,000,000
• 1 ≤ enemy[i] ≤ 1,000,000

보다시피 enemy의 길이가 너무 크다..2 가지의 경우를 나눠서 DFS 해주기엔 시간복잡도가 2^1,000,000이 나오게 된다.. 그렇다면 최소 Nlog(N)의 복잡도를 사용해야 한다.

반복문을 한 번만 돌아한다는 말인데..여기서 고민 끝에 내린 결론이 heap을 사용하자였다.

1. enemy 반복문을 돈다.
2. enemy[i]가 n보다 작으면 맞서 싸운다. (answer+=1)
3. enemy[i]가 n보다 크면 무적권을 쓴다. (1) 이 전에 맞서 싸운 enemy중에, 더 큰 enemy가 있다면 그때 enemy에게 무적권을 쓴걸로 치자 ! (이를 위해 heappop을 쓴다) (2) 더 큰 enemy가 없다면, 지금 쓴다. (3) 첫 싸움이면 무조건 무적권을 쓴다.(무적권 없으면 끝 answer 출력)

내가 쓴 풀이

이해를 돕고자 리팩토링을 안 했습니다..위에 과정 그대로 해설 시작 참고로 여기서는 MaxHeap을 쓰고자, (-)를 곱해서 heappush를 했다.

import heapq
def solution(n, k, enemy):
    answer = 0
    h=[] # heap배열
    for i in enemy: # enemy 반복문을 돈다.
        if n>=i: # n보다 작으면 맞서 싸움

            n-=i
            heapq.heappush(h,-i) # 기록한다.
            answer+=1

        elif n < i and k != 0: # n보다 크면 무적권을 씀

            if h and -h[0]>=i: # 이 전에 맞서 싸운 더 큰 enemy가 있다면
                a=-heapq.heappop(h)
                n+=a # 그때 무적권을 썼던 것으로 친다.
                k-=1
                n-=i
                heapq.heappush(h,-i)
                answer+=1
            else: # 이 전에 맞서 싸운 더 큰 enemy가 없다면
                k-=1 # 지금 무적권을 쓴다.
                answer+=1

        elif n < i and k==0: return answer #무적권 없으면 끝 
    return answer

검색 풀이

from heapq import heappop, heappush

def solution(n, k, enemy):
    answer, sumEnemy = 0, 0
    heap = []

    for e in enemy:
        heappush(heap, -e)  # 현재 적을 힙에 추가
        sumEnemy += e       # 현재까지의 적의 합을 더함
        if sumEnemy > n:    # 적의 합이 n을 초과하면
            if k == 0:      # k가 0이면 더 이상 처리 불가, 루프 종료
                break
            sumEnemy += heappop(heap)  # 가장 큰 적을 되살림으로써 합을 줄임
            k -= 1         # k를 하나 소모
        answer += 1        # 적을 처리했으므로 answer를 증가
    return answer          # 최종 처리한 적의 수 반환

처리 시간은 비슷한데 훨씬 깔끔하다. 리팩토링 된 느낌인데, 실전에서 이렇게 깔끔한 코드를 생각하는 게 관건인 것 같다.. 그래도 저번에 호텔 대실 문제를 풀면서 heap은 생각도 못 했는데, 이번 알고리즘 문제를 풀면서 heap을 어떤 식으로 활용해야 하는지 감이 온 것 같다.

// HashMap 선언
Map map = new HashMap();
map.put("name", "a");
map.put("age", 100);
map.put("name", "b"); // 처음 대임된 a -> b로 변경 됩니다.

// 결과
// key : name, value : b
// key : age, value : 100
for (Object o : map.keySet()) {
    System.out.println("key : " + o.toString() + ", value : " + map.get(o));
}

map.keySet();                             // key 값들을 Set 형태로 모두 불러옵니다.
map.values();                             // value에 해당하는 값들을 Collection 형태로 불러옵니다.
map.get("name");                          // key에 해당하는 값을 읽기
map.getOrDefault("address", "Not Found"); // key에 해당하는 값이 없을 경우 default 값을 참조
map.containsKey("email");                 // key 값이 map에 포함하는지 확인
map.remove("name1");                      // key에 해당하는 값을 제거
map.clear();                              // 모든 map 내부 데이터 제거

Map map2 = new HashMap();
map.put("name", "aa");
map.put("age", 200);

// 결과
// {name=aa, age=200}
map.putAll(map2);                         // map에 map2의 값을 대입합니다.

도넛과 막대 그래프

import java.util.*;

class Solution {
    public int[] solution(int[][] edges) {
        Map<Integer, Integer> out = new HashMap<>();
        Map<Integer, Integer> in = new HashMap<>();
        int[] answer = new int[4];

        for (int[] edge : edges) { // (1)
            out.put(edge[0], out.getOrDefault(edge[0], 0) + 1);
            in.put(edge[1], in.getOrDefault(edge[1], 0) + 1);
        }

        for (int node : out.keySet()) {
            if (out.get(node) > 1) { // (2)
                if (!in.containsKey(node)) {
                    answer[0] = node;
                } else {
                    answer[3] += 1;
                }
            }
        }

        for (int node : in.keySet()) {
            if (!out.containsKey(node)) { // (3)
                answer[2] += 1;
            }
        }
        answer[1] = out.get(answer[0]) - answer[2] - answer[3]; // (4)
        return answer;
    }
}

다른 풀이

public class HashEx {
    public int[] solution(int[][] edges) {
        int[] answer = new int[4];
        Map<Integer, int[]> map = new HashMap<>();
        for (int[] edge : edges) {
            map.put(edge[0],map.getOrDefault(edge[0],new int[]{0,0}));
            map.put(edge[1], map.getOrDefault(edge[1], new int[]{0, 0}));
            map.get(edge[0])[0]++;
            map.get(edge[1])[1]++;
        }
        for(Map.Entry<Integer,int[]> entry : map.entrySet()){
            int Key = entry.getKey();
            int[] val = entry.getValue();
            if (val[0] >= 2 && val[1] == 0) {
                answer[0] = Key;
            }
            // 막대 모양 그래프의 수 확인
            else if (val[0] == 0 && val[1] > 0) {
                answer[2]++;
            }
            // 8자 모양 그래프의 수 확인
            else if (val[0] >= 2 && val[1] >= 2) {
                answer[3]++;
            }
        }
        // 도넛 모양 그래프의 수 확인
        answer[1] = map.get(answer[0])[0] - answer[2] - answer[3];
        return answer;
    }

Stack

추가로는 add와 push를 사용 가능하다. 삭제로는 pop 사용

    public static void main(String[] args) {
        Stack<Integer> stk = new Stack<>();
        stk.push(2); // push사용 
        stk.add(3); //add 사용
        System.out.println(stk);
        stk.pop();
        System.out.println(stk);
    }

결과

2와 3이 잘 들어가고, 3이 pop 된 것을 확인할 수 있다. push와 add의 차이 push()는 stack에서 제공, add()는 List에서 제공하는 메서드 push()의 리턴값은 추가한 객체이고, add()의 리턴값은 boolean이다. Stack에서는 push()를 쓰는 것을 추천한다. 그래야 스택 사용을 알아보기 쉽다.

Deque

기본적으로 ArrayDeque<>()를 사용한다. 스레드 세이프를 보장하진 않지만, 효율이 좋다고 한다. 자세한 내용은 해당 블로그에서 알아봤다.

    public static void main(String[] args) {
        Deque<Integer> q = new ArrayDeque<>();
        q.addLast(3);
        q.addLast(2);
        q.addLast(1);
        System.out.println(q);
        q.removeFirst();
        System.out.println(q);
        q.removeLast();
        System.out.println(q);
    }

결과

3, 2, 1이 잘 삽입 되었고, 앞에서 3과 뒤에서 1이 잘 삭제 된 것을 볼 수 있다.

1차원 배열 정렬

파이썬에서 주로 arr.sort()로 쓰이는 기능이다.

    public static void main(String[] args) {
        Integer[] arr = {1, 26, 17, 25, 99, 44, 303};
        Arrays.sort(arr);
        System.out.println("Sorted arr[] : " + Arrays.toString(arr));
        Arrays.sort(arr, (i1, i2) -> i2 - i1);
        System.out.println("Sorted arr[] : " + Arrays.toString(arr));
    }

Arrays.sort(arr); 이건 짐작하듯 오름차순 정렬 Arrays.sort(arr, (o1, o2) -> o2 - o1); 이게 내림차순 정렬(람다 표현식)이다.

사실 오름차순도Arrays.sort(arr, (o1, o2) -> o1 - o2); 이 표현이 오름차 순인데 그냥 Arrays.sort(arr); 로 간단하게 쓴다.

결과

2차원 배열 정렬

1차원 배열 정렬과 동일한데 , 몇 번째 원소로 정렬할 것인지 index를 넣어준다.

    public static void main(String[] args) {
        int[][] arr = {{2, 4}, {6, 3}, {1, 5}};
        Arrays.sort(arr, (o1, o2) -> o2[1] - o1[1]);
        System.out.println(Arrays.deepToString(arr));
    }

결과

위 코드는 o2[1] - o1[1] 두번째 원소로 내림차순 정렬이다.

아래 코드를 참고하면 o1[n] - o2[n] 을 어떻게 써야하는지 알 수 있다.

Arrays.sort(arr, new Comparator<int[]>() {

    @Override
    public int compare(int[] o1, int[] o2) {
        return o1[0]-o2[0]; // 첫번째 숫자 기준 오름차순 
        return o2[0]-o1[0]; // 첫번째 숫자 기준 내림차순 
        return o1[1]-o2[1]; // 두번째 숫자 기준 오름차순 
        return o2[1]-o1[1]; // 두번째 숫자 기준 내림차순 
    }

참고

가끔 알고리즘 문제 속에, 첫번째요소는 오름차순, 두번째 요소에 대해서는 내림 차순으로 정리해야 할 때가 있다. 아래처럼 작성한다.

Arrays.sort(arr, (o1, o2) -> {
    if (o1[0] == o2[0]) { // 첫 번째 요소가 같을 때
        return o2[1] - o1[1]; // 두 번째 요소에 대해 내림차순 정렬
    } else {
        return o1[0] - o2[0]; // 첫 번째 요소에 대해 오름차순 정렬
    }
});

아래의 결과가 나온다.

Math 클래스

상단에 import java.lang.Math; 추가. 파이썬에서 쓰이던 웬만한 기능들을 사용 가능하다. min(), max(), pow(),sqrt() 등등..

    public static void main(String[] args) {
        int a = -3;
        int b = 2;
        double c = 2.6;
        System.out.println((int)Math.pow(a,b));
        System.out.println(Math.abs(a));
        System.out.println(Math.max(a,b));
        System.out.println(Math.floor(c));
    }

결과

출처 : https://lktprogrammer.tistory.com/114#google_vignette

1. 문제 해석

예약 시간을 담은 리스트를 주고, 최소한의 방을 사용하여 겹치지 않게 고객들에게 방을 내어준다. 사용한 방은 청소시간 10분을 가져야 한다. 위에 1번 예시를 살펴보면, 아래처럼 3개의 방을 사용하여 배정할 수 있다.

2. 문제 접근

book_time의 범위가 (1 ≤ N ≤ 1,000)이 주어졌고, 적은 범위이기에 DP나 브루트 포스 혹은 오래 걸리는 알고리즘까지 생각할 수 있다. 문제는 각 예약에 맞는 방을 배정하면서 겹치지 않는 또 하나의 루프를 생각해야 하는 것으로 보였다. O(N^2)까지 가능한 범위이기에 그리디을 사용했다.

3. 알고리즘 풀이

먼저 주어진 book_time을 int로 바꿔줬다.

for i in book_time:
        for j in range(2):
            h,m=i[j].split(":") # 시간 문자열을 시간과 분으로 분리
            i[j]=int(h)*60+int(m) # 시간과 분을 분 단위로 변환

그리고서 생각할 수 있는 방법은

1. 먼저 방이 아예 없으면 새로운 방을 만들어서 배정한다
2. 방이 있으면 사용 가능 한지 확인한 뒤, 가능하면 배정한다.
3. 사용 가능한 방도 없다면 추가적인 방을 새로 만들어야 한다.

   최종 제출 코드

def solution(book_time):

for i in book_time:
    for j in range(2):
        h,m=i[j].split(":")
        i[j]=int(h)*60+int(m)

book_time.sort()  # 예약 시간을 시작 시간에 따라 정렬
rooms=[] # 방 리스트
for book in book_time:
    if not rooms: # 맨 처음, 방이 없다면
        rooms.append(book) # 방을 만들어줌
        continue

    # 생성 된 각 방을 돔
    for index, room in enumerate(rooms):
        # 대실 시작 시각 >= 퇴실 시간 + 청소시간 10분
        if book[0] >= room[1]+10: 
            rooms [index] = book # 새로운 예약으로 갱신
            break
    else: # 방은 있는데 사용 불가능하다면 방 추가
        rooms.append(book) 
return len(rooms)

이 코드에서는 조심해야 할 점이 if- else를 쓴게 아니라, for - else 문을 이용했다. 
이는 for 루프에서 찾으려는 조건이 충족되지 않았을 때의 대안적인 동작을 제공한다.

for - else는[ 해당 게시물 ](https://velog.io/@black_han26/%EB%B0%B1%EC%A4%80Python-10972-%EB%8B%A4%EC%9D%8C-%EC%88%9C%EC%97%B4)  끝 부분에도 정리해 놓았다.

### (2) heap을 이용한 풀이
```python
from heapq import heappop, heappush

def solution(book_time):
    rooms = []
    book_time.sort(key = lambda _:_[0])
    for book in book_time :
        check_in = num(book[0])
        check_out = num(book[1]) + 10
        if len(rooms) != 0 and rooms[0] <= check_in :
            heappop(rooms)
        heappush(rooms,check_out)
    return len(rooms)

사실 이 코드를 소개해보고 싶어서 글을 썼다. heap을 이용한 알고리즘인데, 실행 결과 속도가 압도적으로 빠르다.앞에 흐름까진 동일하고, 뒤에 방이 존재하고 사용 가능할 때 heappop그리고 heappush를 해주는 점이 다르다..

회고

heap알고리즘은 생각도 못 했기에 소개하고자 글을 썼다.

해당 문제처럼 예약, 대기 시간 문제에서 자주 heap이 쓰이는 것은 알고 있었지만, 아직 응용 능력이 부족하여 이를 활용하지 못했다. Heap 알고리즘은 우선순위 큐를 구현하는데 매우 유용하다. 이를 통해 데이터의 삽입, 삭제, 최솟값 또는 최댓값에 대한 조회를 빠르게 수행할 수 있다. 특히 예약 및 대기 시간과 같은 문제에서는 우선순위에 따라 데이터를 관리하는 것이 중요함을 느꼈다.

heap 개념에 대해서는 아래 두 게시물에서 다뤘었다.

1. heap 알고리즘 문제 회고
2. heappush만 가능할까

이렇게 수행시간이 차이가 날 줄은 몰랐다. 앞으로는 문제 해결에 Heap을 고려하여 보다 효율적인 알고리즘을 구현해보고자 한다.

1. 문제 해석

추가로 정점을 하나 생성하여 각 그래프의 특성에 따라 간선을 연결하고 번호를 부여한다. 이때 주어진 간선 정보를 바탕으로 각 그래프 형태에 대한 정보를 계산한다.

예를 들어, 다음과 같은 간선 입력이 들어온다. 이 간선 정보를 가지고 그래프를 그리면 아래와 같다. 여기서 우리는 2가 추가 된 임의의 정점이라는 것을 알 수 있고, 3-4 막대그래프와 1번 도넛 그래프가 하나 있다는 것을 알 수 있다.

아래 그래프도 마찬가지이다.4번이 추가된 정점임을 알 수 있고, 2번 막대그래프 하나 그리고 8자 모양 그래프 두 개가 있다.

이 정보들을 출력하면 된다.

2. 문제 접근

범위가 1 ≤ edges의 길이 ≤ 1,000,000으로 주어졌고, 최대 Nlog(N)의 알고리즘을 이용해야 한다.

해당 문제는 어떤 정점이 몇개의 간선을 가지고 있느냐로 구분 지어야 하기 때문에 딕셔너리를 이용하기로 한다.

3. 알고리즘 풀이

문제를 살펴보면, 먼저 추가된 정점을 찾아야 구분짓기가 편할 것 같다. 추가된 정점은 그래프 개수만큼 나가는 간선을 가지고 있고 들어오는 간선은 없다.그렇다면 다른 그래프는 어떨까? 먼저 막대그래프 또한 들어오는 간선만 있고 나가는 간선이 없는 정점을 하나씩 가지고 있는 것으로 보인다.

8자 그래프는 2개 이상 들어오고, 2개가 나가는 정점을 하나씩은 가지고 있다. 마지막으로 도넛 그래프는 전체 그래프의 개수 중에 (막대그래프 + 8자 그래프) 개수를 뺀 것과 같다. 전체 그래프의 개수는 임의 정점에서 나가는 간선의 개수와 같다.

def solution(edges):
    answer = [0,0,0,0]
    edge={}
    # 오가는 간선의 개수를 파악
    for a,b in edges: 
        if not edge.get(a):
            edge[a]=[0,0]
        if not edge.get(b):
            edge[b]=[0,0]
        edge[a][0] +=1
        edge[b][1] +=1

    for key, value in edge.items():
        # 임의의 정점
        if value[0]>=2 and value[1]==0:
            answer[0]=key
        # 막대 그래프
        elif value[0]==0 and value[1]>=1:
            answer[2]+=1
        # 8자 그래프 
        elif value[0]==2 and value[1]>=2:
            answer[3]+=1
    answer[1] = edge.get(answer[0])[0]-(answer[2]+answer[3])
    return answer

이번 문제는 딕셔너리에 대해 연습해볼 기회가 되었다. .items() 함수와 .get() 가 어떤 기능을 하는지 확실하게 짚고 넘어가야겠다. items()는 어떤 key와 value의 값이 있는지 확인한다. keys() 와 values()도 있다. 이는 어떤 key와 value가 있는지 각각 확인한다.

.get()은 보통 없는 key에 접근할 때 발생하는 오류를 막기 위해서 사용된다. print(edge['a'])를 하게 되면 a의 value를 출력하는데, 이때 a라는 key가 없다면 오류가 발생한다.

여기서 사용된 원리는edge.get(a)라고 사용하면, key='a'가 있다면 True 없다면 False를 반환한다.

• 딕셔너리 Values 에서 가장 큰 값은 max(my_dict.values())
• Keys 에서 가장 큰 키는 max(my_dict, key=my_dict.get)이다.
• dict정렬은 키 값으로 정렬 dict(sorted(my_dict.items()))
• values 값으로 정렬 dict(sorted(my_dict.items(), key=lambda item: item[1]))

1. 문제 해석

N 자리의 수가 주어지고, 각 자리가 오름차순을 이루는 오르막 수의 총 개수를 구하는 문제이다.(접한 숫자가 같을 경우에도 오름차순으로 간주)

예를 들어, N=4일 때, 1111, 1122, 1234는 모두 오르막 수

2. 문제 접근

N의 범위가 N (1 ≤ N ≤ 1,000)이 주어졌고, 이렇게 적은 범위에서는 주로 DP나 브루트 포스를 생각할 수 있는데 여기서 나는 다이나믹 프로그래밍을 사용했다.

3. 알고리즘 풀이

나열 -> 규칙 찾기 ( 점화식 ) 누구나 아래까지는 나열할 수 있을 것이다. 여기서 대각선 합의 규칙을 찾을 수 있다.

N=int(input())
dp=list([0]*10 for _ in range(N+1))
dp[1]=[1]*10 # 첫 행은 모두 1
for i in range(2,N+1):# 2부터 N+1까지만
    for j in range(10):
        if j==0: #첫 열은 모두 1
            dp[i][j]=1
        else:
            dp[i][j]=dp[i-1][j]+dp[i][j-1]
print(sum(dp[N])%10007)

(2) 리팩토링

사실 아래 코드가 풀이를 검색하면 주로 나오는 코드인데, 직관적으로 와닿지 않았다.

n = int(input())
dp = [1] * 10

for i in range(n-1):
    for j in range(1, 10):
        dp[j] += dp[j-1]

print(sum(dp) % 10007)

왜 1차원 배열을 쓰는지와, 어떻게 dp[j] += dp[j-1] 로 한방에 정리가 되는지..

그림으로 이해하기 쉽게 설명하자면 아래와 같다. 쉽게 설명하자면, 그림처럼 바로 윗줄 행의 값을 더하면 된다는 점과 어차피 필요한 결과는 마지막 행이기에, 그 전의 행들의 값들을 저장할 필요가 없다는 것 같다.

회고

둘다 시간은 같지만, 2차원 배열보다는 1차원 배열이 공간 복잡도 측면에서 더 효율적이다. 그리고 코드도 훨씬 깔끔하다. 다만 저게 무슨 코드인지 직관적으로 알기 힘들었다.(나만 그럴수도..)

코드 깔끔 vs 누가 봐도 이해할 수 있게

후자 풀이는 코드를 보고 해설을 보면 이해가 가능하지만, 막상 시험 당일 저렇게까지 클린하게 떠올리기가 어려울 것 같다는 판단이 든다..

코딩 테스트를 준비하는 입장에서는 짧은 시간 안에 정확한 풀이를 떠올리는 능력이 중요하다. 어떻게 처리해야 하는지 고민하는 시간과 더 넓은 시야를 가져야겠다.

1. 문제 해석

남은 N일 동안 최대한 많은 이익을 얻기 위해 상담을 계획하고 있다. 각 상담은 완료하는 데 일정 기간이 소요되며, 해당 기간 동안 다른 상담을 진행할 수 없고 얻을 수 있는 최대 수익을 계산하는 문제이다.

예를 들어, N=7일 때, 상담 일정이 다음과 같다고 가정하자:

1일차 상담: 3일 소요, 10의 수익 4일차 상담: 1일 소요, 20의 수익 5일차 상담: 2일 소요, 15의 수익

상담이 다른 상담을 진행할 수 있는 기간과 겹치지 않게 스케줄을 짜야 하며, N+1일째 되는 날에는 퇴사 예정이므로 그 전까지 모든 상담이 마무리되어야 한다.

2. 문제 접근

N의 범위가 N (1 ≤ N ≤ 15)이 주어졌고, 시간제한은 2초이기 때문에 어떤 알고리즘을 이용해도 여유로워 보였다. 이럴 경우 DP 혹은, 오랜시간이 걸리더라도 가장 확실한 답이 나오는 브루트 포스를 사용할 수 있다.

나는 후자를 사용했지만, DP를 사용하는 방법도 소개해 보려고 한다.

3. 알고리즘 풀이

1. 트리형태로 상담을 선택했을 때와 선택하지 않았을 때를 나눔
2. 종료 조건 : day가 N이상이 된다면 멈추고, 최대 수익으로 갱신

이는 이전에 작성했던 스타트와 링크 알고리즘 풀이와 유사하다. 1번을 1일차 상담을 선택할 경우와 안할 경우를 나눈다. 마찬가지로 2번과 3번도 나누어 간다. depth가 N이상이 되었을 때는 더 이상 불가능 하기에 return한다.

N=int(input())
arr = [list(map(int,input().split())) for _ in range(N)]
ans=0

#day는 현재 날짜, profit은 현재까지의 수익
def dfs(day,profit):
    global ans # 전역 변수 ans 사용
    # 현재 날짜가 상담 가능 일수 N을 넘으면 현재까지의 수익을 최대 수익과 비교
    if day >= N:
        ans=max(ans,profit) # 최대 수익 갱신
        return

    # 상담 완료 날짜가 N을 넘지 않으면 상담 진행
    if day+arr[day][0] <= N:
        dfs(day+arr[day][0],profit+arr[day][1]) 
    # 상담을 선택하지 않을 경우, 다음 날짜로 넘어감
    dfs(day+1,profit)

# 초기 날짜(0)와 수익(0)으로 DFS 탐색 시작
dfs(0,0)
# 최대 수익 출력
print(ans)

dfs(day+1,profit) 상담을 선택하지 않았을 경우는 날짜만 지나기 때문에 이처럼 작성했다.

(2) DP를 이용한 다른 풀이

1. 날짜를 뒤에서 부터 세면서 DP를 이용한다.
2. dp[0]이 최대 이익이 된다.

N=int(input())
T=[0]*N
P=[0]*N
dp=[0]*(N+1)

for i in range(N):
    T[i], P[i] = map(int,input().split())

# 뒤에서부터 탐색을 시작하여 각 일자에서 얻을 수 있는 최대 이익을 dp 리스트에 저장
for i in range(N-1,-1,-1):
    # 만약 상담을 시작하면 N일 내에 완료 가능한 경우
    if i+T[i]<=N:
        # 현재 상담을 선택하는 경우와 선택하지 않는 경우 중 더 큰 이익을 최대 이익으로 결정
        dp[i]=max(dp[i+1],dp[i+T[i]]+P[i])
    else:
        # 현재 상담을 완료할 수 없는 경우, 현재 일자의 최대 이익은 다음 날과 같다
        dp[i]=dp[i+1]

# 최종적으로 0일차에서의 최대 이익 출력
print(dp[0])

이 풀이에서는 DP를 사용했다.

스타트와 링크 문제와 유사한 알고리즘으로 해결이 가능하지만, DP를 이용하는 것이 신박해서 다시 한 번 기록해봤다.

정처기 합격 기준

총 5과목으로 구성되어 한 과목당 최소 40점은 넘어야 하고, 평균 60점 이상이어야 합격을 할 수 있다.

자격증 시험은 자격증을 취득하는 게 목표라고 생각했기 때문에 커트라인만 넘으면 된다고 생각을 했다.

나는 비전공자였지만, 코딩 테스트를 준비했었고 자바와 데이터베이스도 공부를 했었기 때문에 자신이 있었는데 막상 내용 보니깐 멘붕..😨 처음 보는 내용이 압도적으로 더 많았다.. 코테 준비, 취준, SQLD 준비까지 겹쳐서 실제 준비 시간은 10일 정도 된 것 같다.

공부법

내가 참고했던 자료는 네이버 블로그 이곳을 참고했다. 블로그 정리 내용을 가지고 하루에 한 과목씩 5일동안 개념을 '훑었다' . 솔직히 여기까지는 하루에 2~3시간가량만 썼다. 외우기보단 말 그대로 훑었다. 키워드를 아는 게 중요했고, 실제로 처음 보는 개념이 너무 많았다.. 이거 다 기억하려다가는 머리가 터질 것 같다는 생각이 들었기 때문.

빨리 기출을 풀고 싶었는데 다 읽을 때까지 참았다. 그리고 나서 CBT기출창고 여기서 기출을 풀기 시작했다.

시험까지 5일가량 남은 상태였고 나는 딱 2개년 치만 풀었다. 22년도에 2회분이랑 21년도 3회분.. 총 5번의 기출 처음 푸는 1~2회분은 한 문제씩 풀고 해설을 보며 개념을 익혀갔다. (처음 풀 땐 거의 다 틀리기 때문에 100문제 한 번에 푸는 게 의미가 없음을 느낌..)

여기서 느껴지는 게 앞서 훑었던 개념들이 어떤 식으로 출제가 되고, 어느 부분이 중요한지 알게 되었다. 그리고 3회분부터는 진짜 시험을 보듯 100문제를 풀었고 이때도 해설은 다 읽었다. 가장 중요한 건 3회분부터는 내가 몰랐거나, 아직도 헷갈리는 개념들은 쏙 뽑아서 정리했다.

그렇게 4일간 5회분을 풀고, 시험 보기 전까지 정리했던 개념만 읽었다.

시험 당일

신분증 필수, 참고로 컴싸는 필요가 없었습니다.. 확실히 시험을 보는데, 문제 은행식이라는 느낌이 없잖아 있긴 했다. 소량 몇 문제 정도는 기출과 동일해 보이는? 문제가 나왔다.

그리고 정처기 필기는 시험 제출을 누르면 그 자리에서 화면에 합불 결과와 가채점 점수가 보이는데 맨 앞에 앉아서 살짝 부끄러웠다..

제출 전에 애매한 문제와 틀린 문제를 체크해 봤는데, 평균 60점은 넘을 거 같은데 제5과목이 확신이 없어서 과락이 두려웠다.

고민하다가 결국 제출했고 결과는 79점으로 합격이었다.!! 가채점 결과이며 점수가 올라갈 순 있으나, 떨어지진 않는다고 하니 안심하고 집에 갔다.

필기 후기

아슬하게 합격할 줄 알았는데, 그나~마 안정적이라서 기분은 좋았다. 그리고 어느정도 안다고 자만하며 시작했는데, 개념정리서 첫장을 보니깐 큰일 났다고 생각 들었다.. 사전에 내가 아는 게 도움이 됐던 건 3과목과 4과목이었는데, 그것도 30% 정도?

간혹 머리 비상하신 분들은 5일 만에 하시는 것 같은데, 정말 생노베이스라면 일주일은 시간을 풀로 써야 가능할 것 같다..

이제 다시 정처기 실기, SQLD와 코테등 취준 준비시작..

• 모든 속성은 더 이상 쪼갤 수 없는 하나의 값만 가져야 한다.

다가 속성 ➡ 전화번호가 여러 개 존재. 콤마(,)로 구분되어 있는 것 고객번호가 결정되어도 전화번호가 결정되지 않음.. 즉 전화번호를를 나누고 새로운 테이블을 만들어야 한다. 새로 테이블을 만들때는 새로 생긴 마스터 테이블끼리 관계를 가지고있느냐를 판단..

복합 속성➡ 고객명은 성과 이름으로 복합되어 있다. 이런것을 나누느냐를 판단한다. ex) 주민등록번호 -> 생년,월일 등등..

유사 속성 중첩 릴레이션 ➡ 한 릴레이션에서 반복형태 속성이 있으면 안된다. 이것처럼 반복 속성을 분리한다.

제 2정규화

• 두개 이상의 PK가 존재한다. 모든 비 식별자 속성은 후보 식별자 속성에 완전 함수 종속돼야 한다.

부분함수 종속이 존재하는 릴레이션

A와 B를 통해서 C와 D가 결정되어야 하는데, B만으로도 C를 알 수 있는 상황 즉, B 왕비가 사조직이 있다. -> 왕족의 반란이다. B와C 를 따로 빼서 통치한다. 이는 마스터테이블이 돼서 1:M의 관계를 가지게 된다.

아래 테이블은 소분류와 소분류명으로 묶어서 테이블을 나눌 필요가 있는가 ?

나누었을 때 소분류명이 딱히 의미를 가지지 않기때문에 대분류와 붙여준다.

만약 소분류명이 나누었을 때 의미가 있다면 아래처럼 구분한다.

제 3정규화

-일반 속성간에는 종속성이 존재하지 않는다. 이 테이블은 C가 결정되면 D가 결정된다. 즉 D는 C에 종속된다. -> 왕권은 문제없는데 지방 호족이 사조직이 있다.

C와 D를 내보내서 테이블을 만든다. 마치 2정규화랑 비슷하다.

BC정규화 (잘 나오지않음)

문제없이 A,B가 결정되면 C와 D가 잘 결정되는데, C가 결정되면 PK인 B가 결정된다.

진짜 왕족C는 신분을 속이고 B를 세워놓는다. -> 처갓집의 반란 장인어른이 진짜권력이고 처가 왕비의 역할을 하고있다.

B자리에 C를 PK로 넣어주고, B와 C를 따로 뽑아서 테이블을 만든다. 여기서도 C가 PK가 된다. 결국 장인어른이 PK가 되도록 만들었다.

역정규화

-효율을 위해서 일부를 중복 허용 Join시 발생되는 엄청난 계산량을 해결하기 위해 사용

데이터가 많은데 JOIN을 하자니 너무 오래 걸린다. 그냥 중복되더라도 분리를 시키지않으면 조인을 할 필요가 없어서 빠르게 처리가 가능해진다.

그러나 위 그림처럼 K를 두개의 테이블에 모두 놓으면 실패된 모델링이다. 한곳에만 있으면 됨. 나머지는 FK로 찾아들어간다. 위 그림처럼 고객명이라는 사조직을 가지고 있지만, 일부러 냅둔다.

테이블 관계

1 : M 관계

한쪽이 관계를 맺은 쪽의 여러 객체를 갖는 것

부모와 자식 관계로 볼 수 있다. ➡ 부모의 PK는 자식의 FK가 된다. 자식은 없을 수 있으나, 부모는 존재해야 한다. 즉 부모 없는 자식은 없다 ➡ 오류 발생

1 : M 재귀적 관계

1:M 관계가 너무 많아서 복잡해질 때 자신을 참조하는 관계를 나타내서 표시하는 것 하나의 테이블에 PK와 FK가 있게 설계한다. PK와 부모 ID를 FK로 두고 재귀적 관계를 설정한다.

셀프 조인이라고도 불림. 본인의 상위부서를 확인할 수 있게 한다. 최상위 부서는 상위부서가 존재하지 않기에 null을 허용한다.

M : N 관계

1. 부모 관계가 아니어야 한다. ➡ 마스터 테이블이 서로 독립적으로 존재할 수 있어야 한다.
2. 어느 쪽에서 봐도 다대다 관계가 성립한다.

*헷갈리면, 테이블을 만들어 본다. ! * 예를 들어, 유저가 있고 유저가 팀에 가입하여 팀을 형성한다고 생각해 보자.

1. 먼저 팀은 여러 유저를 가질 수 있다. 이는 마치 부모 관계 인것 처럼 보인다.. 그렇다면 1 : M 관계로 설정할 수 있다. 그런데 만약에 유저는 여러팀에 가입할 수 있다면 어떻게 될까?위 테이블처럼 team테이블에서도, user테이블에서도 중복이 발생한다. 이게 M:N 관계이고 관계 테이블을 만듦으로써 연결시켜 준다. join이라는 테이블을 만들어서 양쪽 마스터 테이블의 PK를 FK로 받는다. 이로써 가입한 날짜를 속성으로 추가할 수도 있으며, 양쪽 테이블을 중복 없이 연결시킨다.

상속형 PK와 독립형 PK

위 관계 테이블에서 join_id가 없고 team_id와 user_id를 복합키로 사용하면 상속형 PK라고 한다. 이는 복합키의 장점을 살리며 join_id를 따로 만들 필요가 없게 한다.

독립형 PK는 위에 그림 그대로이다.

1. 문제 해석

쉽게 말해 5명이 이어져 있는 가를 판단하고, 이어져있다면 1 아니라며 0을 출력한다.

ex )(0-1), (1-2), (2-3), (3-4), (4-5) 으로 1-2-3-4-5가 연결된 것으로 1을 출력한다.

ex )언뜻 보면 (0-1), (1-2), (2-3), (3-0) 으로 0-1-2-3-0 으로 4개만 연결된 것처럼 보이는데, 4부터 시작하는 것을 생각했을 때 4-1-2-3-0 으로 5개가 연결되어 있다.

2. 문제 접근

연결 관계를 확인하고 방문 처리를 해야하는 문제라고 판단이 들었다. 다만, 5개의 연결 관계를 빠르게 파악하는 게 우선이기 때문에 BFS보단 DFS가 더 적합하다고 판단했다.

3. 알고리즘 풀이

A(depth=1)를 시작으로 (depth=5)까지 가게 된다면 5명이 연결된 것으로 간주한다.

1. 처음 start를 시작으로 연결 관계를 확인한다.
2. 종료 조건 : 트리의 깊이가 5가 된다면 멈추고, 1을 출력
3. for i in range(N) 을 통해 start를 바꿔가며 DFS를 실행

N,M = map(int,input().split())
arr=list([] for _ in range(N))
visited=[False] * N
for _ in range(M): # 간선 정보 입력
    a,b=map(int,input().split())
    arr[a].append(b)
    arr[b].append(a)
five = False # 5명 연결시 True

def dfs(start,depth):
    global five
    visited[start]=True

    if depth==5 : # 5명 연결확인
        five = True
        return
    for i in arr[start]: # 연결된 것들중에
        if visited[i] == False : #방문하지 않은게 있는지 확인
            dfs(i,depth+1)
    visited[start]=False


for i in range(N):
    dfs(i,1)
    if five:
        print(1)
        break
else:
    print(0)

처음 나의 풀이 & 회고

for _ in range(M):
    a,b=map(int,input().split())
    arr[a][b]=1
    arr[b][a]=1
five = False

def dfs(start,depth):
    global five
    visited[start]=True

    if depth==5 :
        five = True
        return
    for j in range(N):
        if arr[start][j]==1 and visited[j] == False :
            dfs(j,depth+1)
    visited[start]=False

처음에 위처럼 작성했는데 자꾸 시간 초과가 발생했다. 알고 보니 간선 정보를 2차원 배열에 넣었는데, 이렇게 되면 연결이 되었는지를 확인하기 위해서는 모든 사람을 조사해 봐야 한다는 차이를 깨달았다. List를 이용하면, for i in List 처럼 연결된 사람을 바로 확인할 수 있어서 탐색하는 더 빠르다.

여태까지 DFS 간선 정보를 2차원으로만 사용했는데 List를 이용한 좋은 예인 것 같다.

유일성

쉽게 말해 중복되지 않는가를 말한다. 이름이나 혈액형은 중복되기가 쉽기 때문에 유일성을 보장하지 못한다. 그러나, 주민번호나 전화번호 따위는 중복될 수 없기 때문에 유일성을 보장한다.

최소성

키를 구성하는 속성들 중 가장 최소로 필요한 속성들로만 구성함을 말한다. 예를 들면 학번과 학과의 묶음은 유일성을 보장하지만 학번만으로도 충분히 학생을 식별할 수 있기 때문에 최소성을 보장하지 못한다. 또한 상품 주문을 식별할 때 주문 일자+고객명+상품명으로도 식별할 수 있겠지만, 간단히 주문 번호만으로도 식별을 할 수 있기 때문에 최소성을 고려하지 않은 설계라고 칭할 수 있다.

슈퍼키(Super Key)

유일성을 만족하는 집합

후보키(Candidate Key)

유일성과 최소성을 만족하는 집합 이는 기본 키가 될 수 있는 키의 집합이며, 기본키로 설정되면 나머지는 대체키가 된다.

아래 테이블을 통해 무엇이 유일성과 최소성을 만족하는지 알아보자.

사진 출처: http://dbteam1116.pbworks.com/w/page/38413057/%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD%20%EB%B6%84%EC%84%9D

위의 표에서 후보키는 무엇이 될까? 고객번호, 전화번호, 주민번호가 될 것이다.

Primary Key (PK - 기본 키)

후보키에서 선택받은 키이다.

주민번호나 전화번호 같은 고객의 개인정보는 PK로 사용하는 것을 지양한다.

Foreign Key (FK - 외래 키)

다른 테이블의 기본키를 가져와 관계를 연결시키면 이를 외래 키라고 부른다. 이는 테이블이 다른 테이블의 데이터를 참조하여 테이블간의 관계를 설정한다.

복합키

두 개 이상의 컬럼을 묶어서 하나의 기본키로 지정한다. 이는 하나의 테이블에 하나의 기본키만 존재할 수 있다는 규칙을 위배하지 않는다.

기본키는 하나의 테이블에 하나만 존재할 수 있다. 그런데 데이터베이스 모델링을 하면 하나의 컬럼으로는 기본키를 선택하기 어려운 상황이 발생한다.예를 들면, 위와 같은 반 테이블을 만들고 싶다. 학년, 반, 반이름 컬럼이 있을 때 어떤 것을 기본 키로 설정해야 하는지이다. 학년과 반 이름은 모두 유일성을 위배하기 때문에, 반을 PK로 설정하게 되면, 최대 3반까지만 있는 학교라고 가정했을 때 위에처럼 2학년 부터는 4반, 5반, 6반으로 증가하는 문제가 생긴다. 이럴 때는 학년 컬럼과 반 컬럼을 하나로 묶어서 지정하는 복합키를 사용 한다. 즉, 1-1, 1-2, 1-3, 2-1, 2-2, 3-1처럼 학년과 반을 묶어서 사용하면 유일성을 가지게 된다.

DBeaver에서 복합키 설정

아래처럼 관계도를 만들 예정이다. 1. 먼저 Create New Table로 복합키를 설정할 테이블을 만든다.2. 컬럼에는 아래처럼 부서 이름, 부서id, 회사id를 넣어주었다.3. 그리고 Columns아래 Constraints로 들어가서 Create New Constraint를 선택한다.4. 복합키로 설정할 컬럼을 선택한다. 여기서 이미 PK가 존재한다면, PK를 먼저 삭제하고 진행해야 한다. 5. PK가 2개로 등록이 된 것을 확인 할 수 있다.

결과

여기서는 Companyid와 Deptid의 결합이 PK로 설정되었기 때문에, 아래 그림처럼 총무부를 두번째 INSERT했을 때 Depid가 3이 되지 않고 1이 되는 것을 볼 수 있다.그 이유는 처음 INSERT 한 총무부는 Company id가 1인 회사이기에 PK가 1-1이고, 세 번째 INSERT 한 총무부는 Company id는 2인 회사이기에 Depid를 3을 배정할 필요가 없이 1을 배정하더라도 PK는 2-1로 중복이 된 것이 아니게 된다.

만약 PK를 Deptid 하나로만 설정한다면 아래처럼 Deptid는 1,2,3...으로 증가되게끔 설정된다.그리고 아래처럼 쿼리입력을 하면 '1'은 이미 존재한다는 오류가 나게 된다.

💡 복합키 사용 시 고려해야 할 점

복합키를 사용할 때는 PK로 설정하는 순간, Null을 허용하지 않기 때문에 반드시 데이터값이 들어가야 한다.

그러나 우리가 실제로 데이터 모델링을 할 때는 부모나 자식의 위치를 모르고 일단 INSERT 하게 되는 경우도 존재한다. 예를 들면, 몇 학년인지는 정해졌지만, 아직 반이 정해지지 않았을 경우 복합키를 사용하면 반이 정해질 때까지 INSERT를 할 수 없게 된다. 사용자의 의도를 고려해서 복합키를 사용할 필요가 있다.

회고

키 개념에 대해서 다시 한번 정리하는 계기가 되었다. 특히, 복합키의 개념은 처음 접해보았고, 직접 구현하면서 이를 설정하고 작동하는 방식에 대해 이해하게 되었다. 이러한 경험을 통해 복합키는 나중에 AK(Alternate Key)로도 사용될 수 있음을 알게 되었고, 개념을 정리하는 중요성을 깨달았다.

실제로 기존의 기본 키(PK)를 삭제하고 다시 생성하는 작업에서 몇 가지 어려움을 겪었다. 이유는 먼저 기존의 PK를 삭제하고 PK를 생성시에 하나의 PK는 반드시 설정해야 한다는 오류가 발생했고, 먼저 PK를 생성하고 PK를 삭제했을 때는 한 테이블에는 PK를 하나만 생성할 수 있다는 오류가 발생했다. 이를 해결하기 위해서는 기존 데이터를 먼저 지워야 한다는 점을 알게 되었다. PK를 변경하면 기존 데이터는 변경 전의 PK를 따르고 있기 때문에 이러한 처리가 필요한 것이었다.

이러한 오류 해결을 통해 DBeaver와 같은 데이터베이스 관리 도구에 점차 익숙해지고 있음을 느낀다. 계속해서 경험을 쌓아가면서 데이터베이스 작업에 대한 이해와 능력을 향상시켜 나갈 계획이다.