Добрый день!

Стоит разработать схему БД информационной системы "Телефонно-адресная книга". В этом деле опыта немного, так что от ошибок
отнюдь не застрахован. С вашей помощью надеюсь избежать этих самых ошибок, а также выслушать все замечания и предложения по оптимизации схемы БД.

Итак, исходные требования к ИС ( сам же требования и выдвигал ):

1. Абонент (Subscriber) ( человек, проживающий по определенному адресу и имеющий доступ к телефону) имеет как домашний, так может иметь и мобильный телефон.

2. Абонент может иметь несколько адресов (Address), каждый адрес, соответственно, может иметь несколько абонентов ( многие ко многим ).

3. По одному адресу может находиться несколько телефонов ( Home_Phone ), но один телефон не может принадлежать многим адресам (связь 1 ко многим).

4. Абонент может иметь мобильный телефон (Mobile_Phone), так и не иметь. При этом номер мобильного телефона может принадлежать только одному абоненту.

5. У определенного адреса может быть телефон, но может быть ни одного абонента.

Ну, в общем, как-то так...

Спасибо!

guest_20040621> Стоит разработать

>Полагаете? ;)

Пропустил слово: стоит задача разработать. Разрабатываю я исключительно для себя. Задача: поднабраться опыта в проектировании БД и построении к ней (базе) различных sql-запросов.

> информационной системы "Телефонно-адресная книга"

<VoIP как вариант голосовой связи вы категорически не рассматриваете?

Не рассматриваю.)) Сначала хочу что-нибудь относительно попроще реализовать ( для себя). А потом уже можно и за более серьезные вещи браться =)

> один телефон не может принадлежать многим адресам

<Интересное утверждение. Как минимум сервис 800* ему не соответствует. И как бы никто не обещал, что внутренняя АТС <обязана быть территориально ограниченной, хотя и имеющей один внешний номер публичной сети. Про стандартные короткие <номера, наверное, нет смысла напоминать?

Признаться, я не сильно владею информацией относительно распределения телефонных номеров. Если один телефонный номер может принадлежать многим адресам, то не вопрос -- организуем связь "многие ко многим" ( Address-Home_Phone).

> Ну, в общем, как-то так...

<Определитесь, что вы хотите получить. Если телефонную книгу, скажем, абонентов ТС - частных лиц, то можно оставить <структуру в описанном вами виде, приведя описание территориальной части к стандартному виду (поищите, здесь обсуждается <регулярно). А если вы делаете нормальный телефонный справочник, то переделывать нужно все.

Поясните, пожалуйста, чтобы Вы переделали, делая "нормальный телефонный справочник"?

guest_20040621> Стоит разработать

>Полагаете? ;)



Пропустил слово: стоит задача разработать. Разрабатываю я исключительно для себя. Задача: поднабраться опыта в проектировании БД и построении к ней (базе) различных sql-запросов.

guest_20040621 <VoIP как вариант голосовой связи вы категорически не рассматриваете?

Не рассматриваю.)) Сначала хочу что-нибудь относительно попроще реализовать ( для себя). А потом уже можно и за более серьезные вещи браться =)

guest_20040621 один телефон не может принадлежать многим адресам

<Интересное утверждение. Как минимум сервис 800* ему не соответствует. И как бы никто не обещал, что внутренняя АТС <обязана быть территориально ограниченной, хотя и имеющей один внешний номер публичной сети. Про стандартные короткие <номера, наверное, нет смысла напоминать?



Признаться, я не сильно владею информацией относительно распределения телефонных номеров. Если один телефонный номер может принадлежать многим адресам, то не вопрос -- организуем связь "многие ко многим" ( Address-Home_Phone).

guest_20040621
<Определитесь, что вы хотите получить. Если телефонную книгу, скажем, абонентов ТС - частных лиц, то можно оставить <структуру в описанном вами виде, приведя описание территориальной части к стандартному виду (поищите, здесь обсуждается <регулярно). А если вы делаете нормальный телефонный справочник, то переделывать нужно все.

Поясните, пожалуйста, чтобы Вы переделали, делая "нормальный телефонный справочник"?

Dimitry SibiryakovНет смысла делить телефоны по двум таблицам. У мобильных достаточно оставить пустую ссылку
на адрес.


Поясните, пожалуйста, как Вы себе это представляте и как это будет реализовано (пока не совсем понял Вашу мысль)


Dimitry SibiryakovИзбыточно привязывать абонента к адресу, достаточно связи через телефон.


Т.е. оптимальнее делать привязку абонента к телефону? Т.е. телефоны связать с адресами, а абонентов с телефонами? Почему это оптимальней, ведь по структуре это то же самое, что и привязка абонентов к адресам?

Кстати, правильно ли определены мощности отношений?

Самые популярные запросы будут:

-- поиск по телефону;
-- поиск по ФИО;
-- поиск по адресу;
-- поиск по email.

Dimitry Sibiryakovjuventineне совсем понял Вашу мысль
Какое слово из "держать все телефоны в одной таблице" ты не понял?


Повторю вопрос.

Dimitry SibiryakovНет смысла делить телефоны по двум таблицам. У мобильных достаточно оставить пустую ссылку
на адрес.



Я не представляю себе, как это должно быть реализовано физически ( возможно, отсутствие необходимых знаний и должного опыта тому виной). Хорошо, мы не "делим телефоны по двум таблицам" , запихиваем всю информацию, касающихся телефонов, в таблицу "Телефоны". То есть, отныне будет три сущности "Адреса", "Телефоны", "Абоненты". Адреса, по вашему, будут связаны с телефоном, телефон -- с абонентами.

Не совсем понимаю: "оставить пустую сслыку на адрес". Расшифруйте, как вы себе это представляете физически.

Сущность "телефоны", включающая и городские и домашние, будет связана "Адреса". Внешним ключом будет id_Адреса. "Телефоны" будут связаны с "абонентом" связью многие ко многим. А теперь картина: абонент имеет 10 мобильных телефонов. И у нас, в таком случае, будет 10 строк, где будет отсутствовать инфа по городским телефонам. Как потом искать абонента по номеру мобильного телефона в такой ситуации я тоже не представляю (кстати, какой первичный ключ вы предлагаете сделать в такой таблице?). И потом: связь "телефоны"-"абоненты" предполагается многие ко многим ( один городской номер может иметь много абонентов, один абонент может иметь много городских номеров). В то время как один абонент может иметь много мобильных номеров тел-ов, но реально один номер мобилы может принадлежать одному абоненту (один ко многим)...

В общем, вопросы...

Спасибо!

Dimitry SibiryakovjuventineНе совсем понимаю: "оставить пустую сслыку на адрес". Расшифруйте, как вы
себе это представляете физически.
Nullable поле, содержащее NULL. Знаешь что такое NULL, нет?..


Боже мой...Изначально же ведь сказал, что опыта нет. Можно ж как-то разжевать (если, конечно, есть такое желание), а не кидаться обрывками фраз. Растолковать, какие в таком случае ключи будут
в таблице "Телефоны", как организованы связи. Конкретно, так сказать, указать, а не водить за нос.


Что такое NULL, я, слава Богу, знаю.. А вот что обозначает фраза "пустая ссылка на адрес", не представляю. Можно, конечно, предположить, что при заполнении поля "мобильные телефоны" значение внешнего ключа ID_Адрес будет равняться NULL, но что тогда делать с городским телефоном, вписанным в эту же строку таблицы и всегда ссылающимся на адрес?


juventine"Телефоны" будут связаны с "абонентом" связью многие ко многим.
С какого перепою? Абонент у телефона всегда один. Когда ты звонишь на городской телефон,
ты же не спрашиваешь "куда это я попал", или таки да?..
[/quot]

В своей БД я хочу реализовать следующее: если человек прописан по какому-то адресу, значит он абонент. В квартире живет семья из 4-х человек -- каждый из них является абонентом. Может, это и неправильно с точки зрения законодательства и противоречит определению слову абонент, но у меня задумано так.

Cane Cat Fishernovexelfjuventine,

еще нужна табличка для людей

Персона (IdПерсоны, ФИО, ДатаРождения).

Да уж, без даты рождения - какие могут быть телефонные разговоры.

А так, чуть что - "Молодой ишо указывать! Иди, пятую нормальную форму учи!".

Что Вы имеете ввиду?

novexelfjuventine,

я бы сделал классификатор видов связи ВидыСвязи (IdВидаСвязи, НаименованиеВидаСвязи), куда можно было бы внести: стационарный телефон, сотовый телефон, e-mail, корпоративный телефон и т.д.

далее сделал бы таблицу для хранения информации собственно о связи Связь (IdСвязи, Инфа, IdВидаСвязи, IdПерсоны, Комментарий).

Инфа - поле для хранения номера телефона либо e-mail и т.д.
Коментарий - текстовый комментарий, на всякий случай :-)

Таким образом в одной таблице можно свести все виды связи и при необходимости расширять классификатор видов связи, например добавлять ICQ, Skype, что там еще появится через 10 лет.

у меня кстати несколько сотовых, более 3 e-mail, есть ICQ, есть рабочий телефон, но нет домашнего телефона.

с адресами поступил таким же образом, создал бы таблицу ВидыАресов (IdВидаАдреса, НаименованиеВидаАдреса), куда можно внести: Фактический, Регистрационный, Временный и т.д.

И соответственно таблицу Адрес (IdАдреса, Адрес, IdВидаАдреса, IdПерсоны, Комментарий)

Поле адрес может иметь разные вариации, вплоть до того, что будет заменено группой полей.

Все согласны с идеей? Мне кажется, что проще разнести информацию ( email, скайп и т.д. -- если несколько адресов почты, скайпов и т.д. ) по разным таблицам ( таблица). И сделать привязку к абоненту. Или я не прав? И, мне кажется, такая схема БД не совсем оптимальна в плане того, если придется менять, удалять какую-то инфу, добавлять. Т.к. сказать, могут возникнуть вопросы целостности.

Кстати говоря, каким образом в предложенной мной модели строить индексы? По каким полям?