동감합니다.. 이론적 정의를 외우고 지문에서 관련성을 찾아야지만 자격증 시험 문제를 풀 수 있다보니 교재들도 다 그렇게 설명하는데, 그렇게 푼 문제들이 실무에 임할 수 있다는 자격을 증명할 수 있는 지에 대해선 회의적이네요. 지금 대부분의 국가자격증들은 실무에 잘 쓰이지도 않는 눈먼 지식들을 암기하게 하면서 시간을 낭비하면 주는 자격증이죠...
제1.0형 - 한 칸에 한 값 제2.0형 - 한 판에 한 뜻, 머리가 둘 이상일 때, 공통된 말만 들어야 함 제3.0형 - 한 판에 한 뜻, 머리 말만 들어야 함 제3.5형 - 다른 판 머리말을 들으면 내 판에서 나가야함 제4.0형 - 몸통끼리 싸울 수 있으므로 서로 다른 판에서 놀게 해야함 제5.0형 - 쪼개서 모든 1:1 조합 개인적으로 0, 1, 2, 3, 4, 5형으로 바꾸고, 역정규화까지 붙여서 -5, -4, -3, -2, -1, 0, 1, 2, 3, 4, 5으로 하면 좋겠네요. 안되겠지만... 정규화 안된 건 i(...)
내부회계 구축 자문용역이나 감사 하면서 맨날 마스터 데이터에 입력 및 수정시 승인권자의 승인을 득하는 통제 강조하면서도 마스터 데이터가 정확히 뭔지는 모르고 걍 대강 이런 걸 마스터데이터라고 부르니까.. 하는 감 정도만 가지고 있었는데 파이썬 공부하고 데이터분석 조금씩 공부하면서부터 개념이 명확하게 자리잡히기 시작했음... 거래처 정보, 인사 정보, 고정자산 정보 죄다 정규화된 데이터들..
DBA 해서 밥 먹고 있습니다. 스새임 제발 개발자용 인덱스 생성 및 인덱스 잘 태우는 쿼리 작성법 좀 강의 부탁드립니다. 일억개 빌어요 ㅠ 컬럼에 함수 씌우는 개발자, 코드 컬럼 하나에 인덱스 만드는 개발자, where절에 먼저 쓰면 먼저 인덱스 타는 줄 아는 개발자들 덕분에 오늘도 미춰버리겠습니다.
인덱스 외에도 전 아래 쿼리가 더 심각하다고 생각해요 + 과도한 인라인뷰와 인라인뷰안에 with절 쓰는 개발자 + select 스칼라 인라인에 쓰고 아웃라인에서 where로 쓰는 개발자 후자 미쳐버리죠 ㅋㅋㅋ 1.펑션 많이 쓰는건 과거에 sp로 짠 시스템들때문에 생긴 관행(습관) 같고요... 복잡한거나 단건 조회는 몰라도 코드는 아우터로 해야하는데... 2.코드 컬럼 인덱스는.... 하는사람 잘 못봤는데... 대량데이터 배치여도 효과가 없는건가요? 3.where 순서는 옵티마이저가 알아서 할텐데... 힌트를 줘도... 이런분들은 in절에 union 쓰고 별짓 다하겠네요....
@@gobed1 정답은 없죠... 매번 상황과 데이터양에 따라 쿼리 효율성은 다르죠 다만 with문 자체가 임시테이블이어서 추린 데이터가 많지 않고 여러번 참조해야 한다면 효율적이지만(잘 정리해서 쓰면 가독성 좋을때도) 그게 아니라면 성능에 영향만 미쳐서 대부분 못쓰게 하죠 그런걸 다 고려해가며 쓰는사람이 없기에...
선생님 유익한 강의 감사합니다 정규화 작업은 엑셀로 데이터를 정리한다해도 그리 복작하지 않았어요. 그런데 혹시 영상에서 설명하신 여러 이유 중 하나로 정규화된 데이터들을 합쳐서 비정규화하고 싶을 때를 위한 방법, 변환 프로그램이 따로 있을까요? 사실 대부분은 보기 편리하기 위함이니 비정규화해서 볼 수만 있어도 해도 감지덕지할 것 같습니다
엑셀로 조인하려면 1. 룩업함수 노가다 2. 파워쿼리 // 둘 중 하나로 하시는 걸 추천합니다. 테이블의 형식이 아직 고정적이지 않고 유동적이면 비교적 편집이 쉬운 룩업함수 노가다를 추천드리고, 테이블의 형식이 비교적 고정적일 경우 파워쿼리를 추천드립니다. 룩업함수 노가다할 시, 수정이 편하고 값의 변환이 바로 적용되는 게 장점이지만, 셀개수가 많으면 CPU와 메모리 부하가 커지므로 자동계산을 off해야하는 단점이 있습니다. 파워쿼리는 피벗테이블처럼 새로고침 한 번에 한 번 연산하는 식이라 필요할 때만 연산시키니 부하가 없는 게 장점입니다. 룩업함수 외 다른 함수작업을 곁따리로 같이 붙인 게 수만 셀이라면 특히 파워쿼리가 나을 수 있습니다. 단점은 수정이 다소 불편할 수 있고 마스터테이블의 값에 변경이 있을 때 조인테이블에는 바로 적용이 안되는 게 단점입니다.
ㅋㅋ 저두 C계열시... Pos시스템 개발시 고객은 여러명 이지만, 고객번호는 유일성을 가진다. 기업 입장에서는 1대 다 이지민, 상품은 그 유니크한 고객이 구입한 상품만 매칭되어 들어가야한다. 등이 고민이였고, 테이블을 나누어 관리하는 것과 중복제거 안되는 일반키를 고객번호를 두고 그에 매칭하는 부분을 상품번호를 외래키를 두어 고객과 상품의 관계를 매칭시켰습니다.
6:45 출신대학이 강사의 partial dependency가 아닌 이유 설명해주실 수 있을까요? 1NF 메인 테이블에서 가격컬럼이 프로그램컬럼에 따라 결정 되므로 2차 정규화 과정에서 제거 된건데 , 출신 대학은 강사에 의해 결정되니까 마찬가지로 partial dependency아닌가요? 헷갈리네요.
영상에서 제3정규화는 개명이 아니라 강사의 대학변경때문인데 물론, 대학을 자주 바꾸지는 않습니다만 실무로 치면 강사정보에 대학만 딸랑 들어가있을리가 없죠. 강사에게 월급도 줘야 하고, 강사 연락처도 넣어야 하죠. 그리고 강사가 자주 바뀐다면 그것도처리해야하고요. 따라서 강사정보 테이블이 분리되는건 당연한 결과가 됩니다.
