IT/모바일
저자: 이재학
출처: 『IT CookBook, 데이터베이스 개론과 실습: ERwin과 오라클』 "현장의 목소리" 중에서
필자는 그동안 데이터베이스를 접하면서 느낀 점과 절대적인 관점에 대해 살펴보고자 한다. 필자의 개인적인 소견이기 때문에 다소 반발하시는 분도 있으시리라 생각되지만, 그냥 참고한다고 생각하고 읽어보길 바란다.
데이터베이스에 대한 오해
일반적으로 데이터베이스에 대해 몇 가지 오해하고 있는 점들을 살펴보겠다.
1. MSSQL = MYSQL = SQL ??
필자의 대학시절 학과의 소프트웨어 중에 MSSQL Server7.0이 있었다. 대부분의 사람들은 SQL이라고 짧게 이야기했으며, 필자는 이것에 대한 불만을 토하고는 했다. 시간이 흘러 후배들이 MYSQL을 배우기 시작했다. MSSQL Server는 만져보지도 않았다. 역시 대화를 해보면 MYSQL도 SQL로 둔갑해 있었다. 대화는 대충 다음과 같았다.
후배: “선배.. SQL 좀 가르쳐줘요~! 네~ *^^*”
필자: “SQL? MSSSQL?”
후배: “MSSQL이요..”
필자: “그럼 MSSQL이라고 해야지.. 왜 SQL이라고 하냐? 어!? 함 죽어볼텨?? ㅡ,.ㅡ^”
후배: “….”
졸업 후 회사에 가서도 마찬가지로 모두 통틀어 SQL로 부르고 있었다. 정말 모르고 부르는 것일까? 분명히 MYSQL과 MSSQL Server는 DBMS(DataBase Management System)이고 SQL은 Structured Query Language로 하나의 언어다. 물론 문맥을 살펴보면 당연히 DBMS를 이야기하는 것인지 언어를 이야기하는 것인지 알 수 있다. 그럼 왜 오라클은 SQL이라고 하지 않고 오라클이라고 하는 것일까? 그나마 SQL Server라고 하는 것은 좀 낫다. 그러나 이것도 애매하다. 필자가 알기로는 SyBase SQL Server도 SQL Server다.
이제까지 이야기한 것을 모르는 DB쟁이는 없으리라 생각한다. 간혹 이런 것을 왜 따지냐고 말하는 이들도 있겠지만 필자가 이야기하고자 하는 것은 DB쟁이로서 지켜야 할 기본적인 마인드를 말하고자 함이다. DB쟁이들은 데이터를 다루고 정보를 다루는 사람들이다(물론 DB쟁이들뿐만 아니라 소프트웨어 하드웨어 기술자 모두 정보를 다루고 데이터를 다룬다). 그렇다면 최소한 DBMS 명칭을 사용할 때도 정확하고 올바르게 사용해야 하는 것이 아닐까.. 생각해본다.
2. 데이터베이스는 데이터 저장소다.
아마도 데이터베이스를 단순한 저장 공간 정도로 생각하는 사람들도 많이 있을 것이다. 일반적으로 ASP나 PHP 등을 공부할 때나 심지어는 책에서조차 데이터베이스는 그저 “연동”해서 사용하기만 되는 줄 안다. 그렇기 때문에 많은 이들이 데이터베이스는 단순한 저장소인 줄 아는 것이다.
하지만 데이터를 저장하기만 하는 것이라면 굳이 비싼 DBMS를 사용하지 않아도 하드디스크나 기타 다른 저장소에 저장해도 무관하며 오히려 비용도 매우 싸다. 데이터베이스는 저장이 목적이 아니라 자료를 효율적으로 정리/저장하고, 이 데이터를 처리를 통해 원하는 정보를 얻기 위해서 사용하는 것이다. 데이터베이스는 정보를 얻기 위한 하나의 복잡한 메커니즘이라는 것을 잊지 말자.
3. 이론보다는 실무에서 배우는 것이 빠르다 ?
필자는 “실무에서 빠르게 배운다” 말이 정말 싫다. 실무에서 무엇을 빠르게 배운다는 것인가? 절대 불가능하다. 용어 몇 개 안다고 그것이 가능하리라는 생각은 버려야 한다. 물론 그 실무 경력을 많이 쌓는다면 많이 배울 수 있다. 하지만 이것이 빠르게 배운 것인가? 절대 아니다. 이론을 확실히 익힌 후에야 실무에서 배우는 지식들이 좀더 빠르게 자신의 지식이 되는 것이다.
필자가 여러분에게 한가지 문제를 제시할 테니 시험삼아 풀어보기 바란다. 사원 개체집합과 부서 개체집합이 있다. 물론 부서:사원 = 1:다의 관계다. 관계이름은 “소속되다”쯤으로 해두자. 물리적으로 구현되면 사원테이블 쪽에 부서번호라는 컬럼이 있을 것이고 이것은 부서테이블에서 온 외부키다(외부키는 관계의 물리적인 표현이다). 그 외부키에는 NULL 값이 허용되었다. 이 NULL 허용이 뜻하는 바가 무엇인가?
이것을 모른다면 다음부터 데이터베이스를 처음부터 다시 배워야 한다. 자칫 잘못하면 “전산화”가 “내멋대로화”가 되어 버린다. 이론이 받쳐주지 않는다면 모래위에 성을 쌓는 것과 같다. 1, 2, 3도 모르는 아이에게 사칙연산 가르쳐 주면 알겠는가?
나름대로 이유가 있는 말들..
이번에는 나름대로 이유가 있는 말을 살펴보겠다. 어디까지나 필자의 개인적인 의견이라는 점을 상기했으면 한다.
1. 데이터 모델링부터 시작해야 한다!
아직도 프로세스 모델링부터냐 아니면 데이터 모델링부터냐 많이 논쟁하곤 한다. 필자는 데이터 모델링부터라고 감히 말할 수 있다.
정보는 다음 그림처럼 데이터를 처리해서 얻은 결과를 말한다.
만약 이 그림에 고개를 끄덕인 사람이 프로세스 모델링이 먼저라고 우긴다면 그 사람은 데이터 모델링과 프로세스 모델링이 무언지도 모르는 사람이 분명하다. 데이터 모델링에서 정의되는 것은 데이터다. 이 데이터를 처리하면 정보가 된다. 만약 정의되지도 않은 데이터를 처리한다면 분명히 정의되지 않은 정보가 산출될 것이다. 정의되지도 않은 정보를 근거로 의사결정을 한다면 어떻게 될까? 여러분의 상상에 맡기겠다.
2. 튜닝은 어플리케이션(SQL) 튜닝부터...
튜닝이란 말이 난무하고 있다. 휴대폰 튜닝, PC튜닝, 자동차 튜닝 등 많이 있다. 시스템 전체 튜닝에서 애플리케이션 튜닝부터 해야 한다는 이유는 분명하다. 튜닝은 “시스템의 자원을 최대한 활용하게끔 하여 사용자의 정보 욕구를 만족시키는 것”이기 때문이다. 애플리케이션에서 주어진 시스템의 자원을 최대한 활용하게끔 한 다음 모자란다면 하드웨어를 증설하는 것이 당연한 것이다. 만약 시스템의 애플리케이션이 완벽하다고 한다면 당연히 애플리케이션 튜닝을 할 필요가 없을 테지만 그럴 경우는 거의 없다고 생각한다.
3. 데이터베이스는 현실을 반영한다.
위에서 아래와 같은 문제를 냈었다.
사원 개체집합과 부서 개체집합이 있다. 물론 부서:사원 = 1:다의 관계다. 관계이름은 “소속되다”쯤으로 해두자. 물리적으로 구현되면 사원테이블 쪽에 부서번호라는 컬럼이 있을 것이고 이것은 부서테이블에서 온 외부키다. 그 외부키에는 NULL 값이 허용되었다. 이 NULL 허용이 뜻하는 바가 무엇이겠는가?
답은 사원은 자신이 소속될 부서가 없이도(소속될 부서가 결정되지 않았더라도) 존재가 가능하다는 뜻이다. 즉, 회사 사원들 중에서 어떤 부서에도 소속되지 않은 사원이 있는가?라고 했을 때 있다고 한다면 물리적으로는 위처럼 된다. 물론 BPR을 하여 소속부서가 없는 사원은 인사부에 넣으면 되지 않냐고 하여 인사부에 넣으면 된다. 이렇게 된다면 물리적으로는 Default 값이 설정되어야 마땅할 것이다.
다음과 같은 ERD를 그렸다고 해보자.
그리고 테이블을 만들었다고 가정하자.
insert into 사원 value (...)와 같이 사원 테이블에 한 행을 삽입한다고 해보자. 분명히 RDBMS는 오류를 리턴할 것이다. 오라클에서 보면 다음과 같이 ORA-02291에러를 리턴 할 것이다.
단순히 무결성 제약조건 위배인가? 여기에서 끝난다면 안 된다. 이 무결성 제약조건이라는 용어가 현실세계에서 의미하는 바를 정확히 알아야 한다는 뜻이다. 즉, 사원이 소속될 부서가 없기 때문에 일어난 오류임을 알아야 한다. 위 ERD는 사원은 반드시 자기가 소속될 부서를 배정받아야만 그 회사의 사원이 될 수 있으며, 부서의 경우는 그 부서에서 일하는 사람이 없는 부서가 존재할 수도 있는 것이다. 데이터베이스는 현실을 반영한다. 우리가 말하는 “전산화”라는 것은 현실세계의 일을 컴퓨터세계로 옮기는 작업일 뿐이다. 그러므로 현실세계와 컴퓨터세계와는 반드시 “일치성”을 가지는 것이 지극히 정상적임을 알아야 한다.
4. 데이터베이스 관리자의 업무 중 가장 중요한 업무는?
데이터베이스 시스템에서 가장 중요한 것은 무엇일까? 당연히 데이터다. 그러므로 “백업”을 가장 중요한 DBA의 업무로 여기는 곳도 있다. 물론 백업 못지않게 복원도 중요하며, 다운타임을 줄이는 것도 매우 중요하다. 다운타임을 줄인다는 소리는 백업과 복원에 드는 비용을 모두 이야기한다.
한번 더 원천적으로 생각해보자. “문제점이 일어나지 않는 환경”을 만들면 어떨까? 최대한 다운타임을 줄이기 위해서 어떤 노력을 해야 할까? 데이터베이스의 전 분야에 걸쳐 모두 노력해야 한다. 천재지변과 하드웨어 고장을 최대한 막는 환경을 갖추고, 또한 이에 대한 대비를 하는 것이 중요할 것이다. 결론은 중요하지 않은 일이 없다는 것이다.
혹시 데이터베이스에 대해 필자와 논의하고자 하는 독자가 있다면 아래 메일 주소로 언제든 메일을 보내기 바란다.
admin@databaser.net
출처: 『IT CookBook, 데이터베이스 개론과 실습: ERwin과 오라클』 "현장의 목소리" 중에서
필자는 그동안 데이터베이스를 접하면서 느낀 점과 절대적인 관점에 대해 살펴보고자 한다. 필자의 개인적인 소견이기 때문에 다소 반발하시는 분도 있으시리라 생각되지만, 그냥 참고한다고 생각하고 읽어보길 바란다.
데이터베이스에 대한 오해
일반적으로 데이터베이스에 대해 몇 가지 오해하고 있는 점들을 살펴보겠다.
1. MSSQL = MYSQL = SQL ??
필자의 대학시절 학과의 소프트웨어 중에 MSSQL Server7.0이 있었다. 대부분의 사람들은 SQL이라고 짧게 이야기했으며, 필자는 이것에 대한 불만을 토하고는 했다. 시간이 흘러 후배들이 MYSQL을 배우기 시작했다. MSSQL Server는 만져보지도 않았다. 역시 대화를 해보면 MYSQL도 SQL로 둔갑해 있었다. 대화는 대충 다음과 같았다.
후배: “선배.. SQL 좀 가르쳐줘요~! 네~ *^^*”
필자: “SQL? MSSSQL?”
후배: “MSSQL이요..”
필자: “그럼 MSSQL이라고 해야지.. 왜 SQL이라고 하냐? 어!? 함 죽어볼텨?? ㅡ,.ㅡ^”
후배: “….”
졸업 후 회사에 가서도 마찬가지로 모두 통틀어 SQL로 부르고 있었다. 정말 모르고 부르는 것일까? 분명히 MYSQL과 MSSQL Server는 DBMS(DataBase Management System)이고 SQL은 Structured Query Language로 하나의 언어다. 물론 문맥을 살펴보면 당연히 DBMS를 이야기하는 것인지 언어를 이야기하는 것인지 알 수 있다. 그럼 왜 오라클은 SQL이라고 하지 않고 오라클이라고 하는 것일까? 그나마 SQL Server라고 하는 것은 좀 낫다. 그러나 이것도 애매하다. 필자가 알기로는 SyBase SQL Server도 SQL Server다.
이제까지 이야기한 것을 모르는 DB쟁이는 없으리라 생각한다. 간혹 이런 것을 왜 따지냐고 말하는 이들도 있겠지만 필자가 이야기하고자 하는 것은 DB쟁이로서 지켜야 할 기본적인 마인드를 말하고자 함이다. DB쟁이들은 데이터를 다루고 정보를 다루는 사람들이다(물론 DB쟁이들뿐만 아니라 소프트웨어 하드웨어 기술자 모두 정보를 다루고 데이터를 다룬다). 그렇다면 최소한 DBMS 명칭을 사용할 때도 정확하고 올바르게 사용해야 하는 것이 아닐까.. 생각해본다.
2. 데이터베이스는 데이터 저장소다.
아마도 데이터베이스를 단순한 저장 공간 정도로 생각하는 사람들도 많이 있을 것이다. 일반적으로 ASP나 PHP 등을 공부할 때나 심지어는 책에서조차 데이터베이스는 그저 “연동”해서 사용하기만 되는 줄 안다. 그렇기 때문에 많은 이들이 데이터베이스는 단순한 저장소인 줄 아는 것이다.
하지만 데이터를 저장하기만 하는 것이라면 굳이 비싼 DBMS를 사용하지 않아도 하드디스크나 기타 다른 저장소에 저장해도 무관하며 오히려 비용도 매우 싸다. 데이터베이스는 저장이 목적이 아니라 자료를 효율적으로 정리/저장하고, 이 데이터를 처리를 통해 원하는 정보를 얻기 위해서 사용하는 것이다. 데이터베이스는 정보를 얻기 위한 하나의 복잡한 메커니즘이라는 것을 잊지 말자.
3. 이론보다는 실무에서 배우는 것이 빠르다 ?
필자는 “실무에서 빠르게 배운다” 말이 정말 싫다. 실무에서 무엇을 빠르게 배운다는 것인가? 절대 불가능하다. 용어 몇 개 안다고 그것이 가능하리라는 생각은 버려야 한다. 물론 그 실무 경력을 많이 쌓는다면 많이 배울 수 있다. 하지만 이것이 빠르게 배운 것인가? 절대 아니다. 이론을 확실히 익힌 후에야 실무에서 배우는 지식들이 좀더 빠르게 자신의 지식이 되는 것이다.
필자가 여러분에게 한가지 문제를 제시할 테니 시험삼아 풀어보기 바란다. 사원 개체집합과 부서 개체집합이 있다. 물론 부서:사원 = 1:다의 관계다. 관계이름은 “소속되다”쯤으로 해두자. 물리적으로 구현되면 사원테이블 쪽에 부서번호라는 컬럼이 있을 것이고 이것은 부서테이블에서 온 외부키다(외부키는 관계의 물리적인 표현이다). 그 외부키에는 NULL 값이 허용되었다. 이 NULL 허용이 뜻하는 바가 무엇인가?
이것을 모른다면 다음부터 데이터베이스를 처음부터 다시 배워야 한다. 자칫 잘못하면 “전산화”가 “내멋대로화”가 되어 버린다. 이론이 받쳐주지 않는다면 모래위에 성을 쌓는 것과 같다. 1, 2, 3도 모르는 아이에게 사칙연산 가르쳐 주면 알겠는가?
나름대로 이유가 있는 말들..
이번에는 나름대로 이유가 있는 말을 살펴보겠다. 어디까지나 필자의 개인적인 의견이라는 점을 상기했으면 한다.
1. 데이터 모델링부터 시작해야 한다!
아직도 프로세스 모델링부터냐 아니면 데이터 모델링부터냐 많이 논쟁하곤 한다. 필자는 데이터 모델링부터라고 감히 말할 수 있다.
정보는 다음 그림처럼 데이터를 처리해서 얻은 결과를 말한다.
만약 이 그림에 고개를 끄덕인 사람이 프로세스 모델링이 먼저라고 우긴다면 그 사람은 데이터 모델링과 프로세스 모델링이 무언지도 모르는 사람이 분명하다. 데이터 모델링에서 정의되는 것은 데이터다. 이 데이터를 처리하면 정보가 된다. 만약 정의되지도 않은 데이터를 처리한다면 분명히 정의되지 않은 정보가 산출될 것이다. 정의되지도 않은 정보를 근거로 의사결정을 한다면 어떻게 될까? 여러분의 상상에 맡기겠다.
2. 튜닝은 어플리케이션(SQL) 튜닝부터...
튜닝이란 말이 난무하고 있다. 휴대폰 튜닝, PC튜닝, 자동차 튜닝 등 많이 있다. 시스템 전체 튜닝에서 애플리케이션 튜닝부터 해야 한다는 이유는 분명하다. 튜닝은 “시스템의 자원을 최대한 활용하게끔 하여 사용자의 정보 욕구를 만족시키는 것”이기 때문이다. 애플리케이션에서 주어진 시스템의 자원을 최대한 활용하게끔 한 다음 모자란다면 하드웨어를 증설하는 것이 당연한 것이다. 만약 시스템의 애플리케이션이 완벽하다고 한다면 당연히 애플리케이션 튜닝을 할 필요가 없을 테지만 그럴 경우는 거의 없다고 생각한다.
3. 데이터베이스는 현실을 반영한다.
위에서 아래와 같은 문제를 냈었다.
사원 개체집합과 부서 개체집합이 있다. 물론 부서:사원 = 1:다의 관계다. 관계이름은 “소속되다”쯤으로 해두자. 물리적으로 구현되면 사원테이블 쪽에 부서번호라는 컬럼이 있을 것이고 이것은 부서테이블에서 온 외부키다. 그 외부키에는 NULL 값이 허용되었다. 이 NULL 허용이 뜻하는 바가 무엇이겠는가?
답은 사원은 자신이 소속될 부서가 없이도(소속될 부서가 결정되지 않았더라도) 존재가 가능하다는 뜻이다. 즉, 회사 사원들 중에서 어떤 부서에도 소속되지 않은 사원이 있는가?라고 했을 때 있다고 한다면 물리적으로는 위처럼 된다. 물론 BPR을 하여 소속부서가 없는 사원은 인사부에 넣으면 되지 않냐고 하여 인사부에 넣으면 된다. 이렇게 된다면 물리적으로는 Default 값이 설정되어야 마땅할 것이다.
다음과 같은 ERD를 그렸다고 해보자.
그리고 테이블을 만들었다고 가정하자.
insert into 사원 value (...)와 같이 사원 테이블에 한 행을 삽입한다고 해보자. 분명히 RDBMS는 오류를 리턴할 것이다. 오라클에서 보면 다음과 같이 ORA-02291에러를 리턴 할 것이다.
단순히 무결성 제약조건 위배인가? 여기에서 끝난다면 안 된다. 이 무결성 제약조건이라는 용어가 현실세계에서 의미하는 바를 정확히 알아야 한다는 뜻이다. 즉, 사원이 소속될 부서가 없기 때문에 일어난 오류임을 알아야 한다. 위 ERD는 사원은 반드시 자기가 소속될 부서를 배정받아야만 그 회사의 사원이 될 수 있으며, 부서의 경우는 그 부서에서 일하는 사람이 없는 부서가 존재할 수도 있는 것이다. 데이터베이스는 현실을 반영한다. 우리가 말하는 “전산화”라는 것은 현실세계의 일을 컴퓨터세계로 옮기는 작업일 뿐이다. 그러므로 현실세계와 컴퓨터세계와는 반드시 “일치성”을 가지는 것이 지극히 정상적임을 알아야 한다.
4. 데이터베이스 관리자의 업무 중 가장 중요한 업무는?
데이터베이스 시스템에서 가장 중요한 것은 무엇일까? 당연히 데이터다. 그러므로 “백업”을 가장 중요한 DBA의 업무로 여기는 곳도 있다. 물론 백업 못지않게 복원도 중요하며, 다운타임을 줄이는 것도 매우 중요하다. 다운타임을 줄인다는 소리는 백업과 복원에 드는 비용을 모두 이야기한다.
한번 더 원천적으로 생각해보자. “문제점이 일어나지 않는 환경”을 만들면 어떨까? 최대한 다운타임을 줄이기 위해서 어떤 노력을 해야 할까? 데이터베이스의 전 분야에 걸쳐 모두 노력해야 한다. 천재지변과 하드웨어 고장을 최대한 막는 환경을 갖추고, 또한 이에 대한 대비를 하는 것이 중요할 것이다. 결론은 중요하지 않은 일이 없다는 것이다.
혹시 데이터베이스에 대해 필자와 논의하고자 하는 독자가 있다면 아래 메일 주소로 언제든 메일을 보내기 바란다.
admin@databaser.net
TAG :
최신 콘텐츠