Добрый день!

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

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

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, скайп и т.д. -- если несколько адресов почты, скайпов и т.д. ) по разным таблицам ( таблица). И сделать привязку к абоненту. Или я не прав? И, мне кажется, такая схема БД не совсем оптимальна в плане того, если придется менять, удалять какую-то инфу, добавлять. Т.к. сказать, могут возникнуть вопросы целостности.

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

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

Хорошо, я намекну иначе.

Зачем нужна дата рождения в телефонном справочнике?


Ради справочной информации. Чем она помешает?

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

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

Вернемся к семье из четырех человек. Если у одного из них есть мобильник, то остальные три члена семьи тоже являются абонентами этого мобильного номера?

Если уж на городской дяде Ване могут позвонить "здрасьте дядя Ваня, позовите Ирочку", и мы пишем, что Ирочка - тоже абонент этого номера, то мобильник дяди Вани чем хуже?

А если на работе в одной комнате сидят сотрудники Вован и Толян, и в порядке вещей звонок на мобилу "Привет, Вован, дай Толяна, а то у него что-то мобила не отвечает", то надо ли хранить, что Толян - абонент мобилы Вована? Или это только в рабочее время?

Абсолютно согласен.
Но, предположим, у нас справочник, по которому мы должны найти любого жителя небольшого города с определенным местом жительства и информацию о нем ( домашний телефон, по какому адресу проживает)... Что тогда?

guest_20040621> Абсолютно согласен.

Вам пишут чушь, а вы радостно развесили уши.



Ну, то, что, по сути, ни на один из своих ключевых вопросов ( связи, индексы, отношения ) я ответа не получил, то можно с Вами согласиться.

> у нас справочник

Если у вас справочник, то у вас нет неявных соответствий. По определению. Даже вашу схему легко дополнить парой логических признаков типа "стационарное абонентское устройство" и "персональное абонентское устройство", сочетания которых будет достаточно для минимального функционала.



что такое неявное соответствие?) честное слово, впервые столкнулся с таким понятием..=)

> мы должны найти любого жителя небольшого города с определенным местом жительства

Это функционал информационной системы, не нужно туда лезть, у вас нет для этого знаний.
[/quot]

так моя цель как-раз этих самых знаний и набраться =)) а как же их еще набраться, если не ставить перед собой конкретных задач?)

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

Что Вы имеете ввиду под М2? )

Спасибо за совет.

guest_20040621> связи, индексы, отношения

Потому, что сложно отвечать на такие вопросы. Вы сформулировали задачу так: есть набор таблиц, что мне с ним правильнее сделать? Ничего. Потому, что задача должна быть поставлена корректно. Не бывает проектирования ради проектирования, есть конкретные задачи, решение которых представляет собой некую структуру данных. Причем, задача - не теоретические изыскания, а живой (или предполагающийся живым) проект.

> что такое неявное соответствие?) честное слово, впервые столкнулся с таким понятием..=)

Предположим, вы определили, какие стационарные абонентские устройства соответствуют жилым помещениям. Вы определили ответственных квартиросъемщиков или владельцев помещений. Вы определили владельцев стационарных абонентских устройств. Предположим, вы также определили родственные связи между физическими лицами. На основании этих связей вы можете предположить, какой идентификатор стационарного абонентского устройства может соответствовать физическому лицу, если оно не является владельцем стационарного абонентского устройства.

> так моя цель как-раз этих самых знаний и набраться

Вы пытаетесь решать дифференциальные уравнения без знания арифметики. Это абсурдный путь. Начните с "Введения..." Дейта. Затем попробуйте решать простые задачи. Вы, видимо, не понимаете, насколько сложную задачу пытаетесь решить. Вот то, что у вас в таблице фигурирует как поле "ФИО" на самом деле является достаточно часто используемой самостоятельной структурой, для реализации которой вам потребуется как минимум история изменений. Конкретный способ реализации этой структуры будет зависеть от формулирования задачи, но не кривая ее постановка будет включать еще и семантические отношения. Если база данных будет предполагать нормальный жизненный цикл с информационной системой как конечным состоянием, то вы будете вынуждены использовать контексты и перевод. И это одно поле одной таблицы. А вы хотите индексов и связей.

В форумах можно задать конкретный вопрос, чтобы получить конкретный ответ, но искать таким образом знания - плохой путь.

Все понял. Спасибо за совет.