-- 다대다(M:N)관계는 교차(intersection) 엔터티로 푸는게 일반적입니다.
-- 특히 책의 경우는 저자로 연관검색하는 부분이 많아서 주로 분리를 합니다.
-- 전화의 경우도 보통 정규화로 분리를 하는게 일반적입니다.
-- 다만 전화의 활용도가 극히 제한적이라면 그냥 속성개념으로 저자 테이블에 갯수제한적으로 넣을수는 있겠습니다.
-- 하지만 공부하시는 입장이시니 보편적 방법을 선택하시는게 좋겠죠.
-- 아래 링크를 참조하세요.

-- http://wiki.gurubee.net/pages/viewpage.action?pageId=1507663
-- http://m.dbguide.net/knowledge.db?cmd=view&boardConfigUid=20&boardUid=181001

이런 질문들에는 답변을 거의 안달아 주시는 것이 
아마도 명확한 답을 제시하기 어렵기 때문일 것이라 사려 됩니다.
어떻게 설계하든 여러가지 상황에 따라 효율적일 수도 그렇지 않을 수도 있기 때문이죠..

일단 보편적으로 BOOK테이블은 ISBN(PK), BOOK_NAME, PUBDATE, PRICE 이렇게 컬럼을 만들고
AUTHOR 테이블은 ISBK(PK), AUTHOR_ID(PK), AUTHOR_NAME 이렇게 컬럼을 가지고
AUTHOR_TEL_NUM 테이블로 ISBK(PK), AUTHOR_ID(PK), AUTHOR_TELNUM(PK) 이렇게 컬럼을 가질수 있겠네요..

그런데 꼭 저자를 모두 DB에 저장하지 않아도 된다거나
저자를 최대 3명까지만 저장한다거나 (나머지는 000외 0명으로 표기)
여러가지 업무에 따라 AUTHOR_NAME을 그냥 AUTHOR_NAME1, AUTHOR_NAME2, AUTHOR_NAME3과 같은 방식으로
BOOK 테이블에 넣을 수도 있겠죠..

마찬가지로 전화번호 또한 2개까지만 저장한다면 AUTHOR 테이블에
AUTHOR_TELNUM1, AUTHOR_TELNUM2로 만들어 테이블을 하나 줄일 수 있겠네요..

물론 모든 경우의 수를 포함 할 수 있는 보편적인 방법으로 3개의 테이블을 만든다면 확실 하겠지만..
조회 쿼리를 만들어서 프로그램으로 개발할때마다 JOIN 하고
화면에 뿌려주기 위해 피벗 해야 하는 경우도 발생하고
번거롭기도 하고, 때에 따라 오히려 DB에 부하를 유발할 수도 있겠죠.

결론적으로 설계자가 최적이라고 판단되는 방법으로 선택해야겠죠..

창조의 날개님 설계는 저자가 책에 종속적일 때의 설계이네요.
이 경우 author_id 는 큰 의미가 없을듯 하구요 author_name 만 있으면 될 것 같구요.
저자가 책에 종속되지 않고 독립적인 존재라면?
다음과 같이 (저자)와 (책의저자)로 테이블을 분리해야 합니다.
테이블 4개가 필요하겠네요.
1. Book (book_id, book_name, pub_date, price)
2. Author (author_id, author_name)
3. Book_Author (book_id, author_id)
4. Author_TelNum (author_id, telnum)

-- 공부중이시라고 말씀하셔서 생각해보시라고 러프하게 답변을 드렸더니
-- 창조의 날개님, 마농님이 답변을 디테일하게 아주 잘해주셨네요.

-- 이왕 공부하시는 김에 조금만 더 이야기를 진전 시켜보면(^^)
-- 관계형데이터모델링은 미래에 일어날수 있는 행위들을 2차원 데이터 집합들로 
-- 지금 녹여내야하는 쉽지 않은 작업이죠.

-- 가령 위의 예에서도 책의 경우 가격이 책에 1:1의 관계일까요.
-- 일반가가 있을수 있고, 언제부터 언제까지 시행하는 특가 기간의 가격이 있을수 있고
-- 여러가지의 이벤트가격이 있을수 있습니다. 그러면 분리가 되어야겠죠?

-- 그리고 저자의 경우만 있을까요, 번역자,감수자,추천자,출판사등등 따로 다 분리해서 
-- 위의 예를 적용해야 할까요.
-- 아니면 상위 key 엔터티들을 party model 형태로 하나로 통합하고
-- 교차엔터티 item_party를 만들어 itemid,partyid,type(저자로써,역자로써,감수자로써,etc)으로 
-- 가는게 맞을까요.

-- 전화의 경우도 그냥 번호의 나열이 아니라 집전화로써, 모바일폰으로써,사무실로써 등등의 속성이 있을수가 
-- 있으니 구분 속성 타입을 가져가야 할 수도 있겠죠.
-- 생각해보면 여러가지의 가지로 뻗어 나갈수 있을겁니다.^^

-- 이렇듯 모델링은 얼마나 향후 일어날 수 있는 일에 대해 잘 녹여낼수 있는 지에 따라
-- 그 값어치를 알 수 있을 겁니다.

-- 처음엔 성능을 많이 고려하지 마시고 일어날수 있는 일에 대해 최대한 사고 하셔서 
-- 분리 시켜보시고 그 다음에 성능적인 부분을 고려하시는게 좋을 것입니다.

-- 적고보니 두서가 없는데 사견을 한번 적어봤습니다. 즐공하시길~^^

역시 마농님의 세심한 부분까지 고려 하시는 것과

백면서생님의 다양하게 발생할 수 있는 경우의 수까지 고려 해야 한다는 의견까지...

하지만 그 외에도 다양한 방법과 경우의 수가 있을 수 있어 역정규화도 하는거 겠죠...

그래서 이런 질문엔 잘 답변을 안 달아 두시는 것 같은데요..

그래도 서로 의견을 교류 하면서 제가 미처 고려 하지 못했던 부분도 알아 보고 재미 있습니다.. ^^;;