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

Question

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

По сути, я свел контакт к «субъекту» (человеку, компании, роли и т. д.).

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

---

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

Answer 4

Несколько моментов, которые обычно возникают в моем опыте.

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

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