Создание базы данных контактов - нужно немного вдохновения для схемы

Question

Я работал над созданием структуры данных для приложения, над которым я работаю. Одна из вещей, с которой он должен будет справиться, - хранение информации о клиенте / контактной информации. Я изучал интерфейс нескольких различных программ с контактной информацией, таких как Адресная книга, контакты Gmail и т. Д.

Я в основном свел контакт к «сущности» (частному лицу, компании, роли и т. Д.).

• Каждый Объект может иметь несколько Адрес , Телефон , E-Mail записей.
  • Каждый из них определяет «отношения» (дом / работа / помощник и т. Д.)
  • Сущность {1} - {отношение} -> {0 .. *} Данные
• Сущность может иметь несколько полей , которые являются хранилищем данных произвольной формы для других «общих» данных (дни рождения, учетная запись AIM и т. Д.)
  • Сущность {1} - {fieldName} -> {0 .. *} Данные поля
• Субъект может связываться с другим Субъектом , например, как сотрудник , супруга
  • Сущность {0 .. } <- {отношения} -> {0 .. } Сущность

Кто-нибудь делал какие-либо реализации SQL подобных контактных баз данных? Любые идеи / предложения / подводные камни, чтобы вы не могли поделиться здесь с кем-то, кто пытается работать над проектом самостоятельно? Кажется ли то, что я описал, разумным или слишком сложным?

Один вопрос, скажем, у вас есть 4 человека, которые все работают в одной компании. Все они имеют один и тот же «рабочий» номер телефона (возможно, с другим внутренним номером). Если номер или адрес «рабочего» изменится, я хотел бы иметь возможность довольно легко обновить контакты. Теперь многое зависит от того, как вы будете использовать базу данных. Я думаю, что это становится вопросом связывания сотрудников с соответствующими подразделениями компании, но тогда адрес / номер телефона больше не связан напрямую с сотрудником. Я спорю о том, чтобы связать сущность / данные многие со многими, чтобы вы могли привязать один и тот же почтовый адрес / номер телефона к нескольким людям, а обновление его в одном месте может обновить его во всех местах. Я просто слишком обдумал это? вырывает волосы

Answer 1

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

Я бы посоветовал взглянуть на Моделирование ролей объектов (или this тоже), чтобы определить модель на простом английском языке, прежде чем вы на самом деле реализуете любые таблицы. Я использую этот плагин VS: NORMA , который также сгенерирует для вас схему.

В качестве альтернативы, здесь есть модель данных , которая может вас вдохновить. Это «Управление контактами», но есть и другие, например, раздел «Клиенты»

(я просто хотел опубликовать изображение ..)
_{(источник: databaseanswers.org )}

Answer 2

Это просто, чтобы помочь с вашим вторым вопросом; где добавочный номер телефона фактически относится к отношениям между лицом и компанией.

Answer 3

Microsoft предлагает несколько начальных схем баз данных, включая обслуживание активов, управление контактами, заказчиками и заказами, управление документами, электронную коммерцию, службу поддержки, программное обеспечение для отслеживания проблем, контроль розничных запасов и каталоги продуктов. См. Схемы стартовой базы данных .

---

РЕДАКТИРОВАТЬ (апрель 2016 г.). Похоже, что веб-мастер Microsoft разорвал ссылку. Вот архив Wayback Machine страницы.

Answer 4

Пара моментов, которые, как правило, возникают в моем опыте ..

Рассмотрим взаимные отношения. Например, если кто-то определен как сотрудник компании, тогда компания по определению является работодателем этого лица.

Рассматриваете ли вы адреса как сущности сами по себе или просто как свободный текст, связанный с человеком / местом? В некоторых приложениях адрес (физическое здание и т. Д.) Является «реальным», и в таблице может существовать только один адрес. (Часто для этого используется правительственный / почтовый идентификатор).