Пример разработки БД «Записная книжка»

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


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


Хочется подчеркнуть, что повсеместное распространение использования «Контактов» в телефонах сотовой связи и, особенно, смартфонах, позволило на порядок упростить понимание недостатков их реализации. Каждый год студен­ческая аудитория аргументированно приводит свои пожелания и осознает, чем, как и для чего ещё может восполь­зоваться. Тема не относится к «игрушечным», а крайне сложна как в понимании, так и в практическом формирова­нии. Это будет показано в процессе изложения и аргументации.

Излагаемый на странице материал не предназначен для фрагментарного или прерванного прочтения. Настоятельно рекомендуется читать его целиком и сразу (вряд ли менее 2-х часов). Часть сведений, обсуждаемых на занятии, здесь отсутствует, равно как и наоборот. В том числе из-за того, что каждый раз мы идем разными путями.

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

Назначение программы (БД): создание удобной для просмотра и поиска структурированной информационной среды о контактах, отвечающей на любые вопросы.

Основная цель: свести в единой среде различные сведения о людях, обычно заносимые во всевозможные «записные книжки».

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

Задачи:

  1. Исследовать закономерности информационных объектов.
  2. Построить структуру БД.
  3. Создать систему хранения и поиска.
  4. Разработать удобный интерфейс для просмотра и поиска необходимой информации.

Возможные (и не очень) потребители:

  1. «Я сам, собственной персоной», как разработчик!
  2. Безусловно, все люди, так как задача крайне жизненная.
  3. На определенном уровне детализации (перерастание названной темы) — большая часть федеральных организаций. Этот фактор должен несколько притормаживать наши амбиции.
  4. ...

Возможные режимы работы и отчеты на первом этапе оценки.

  1. Просмотр карточки контакта. В значительной степени будет определятся устройством вывода.
  2. Поиск по «имени».
  3. Выбор контактов по стране, городу, полу, возрасту, соцсетям...
  4. Выбор контактов с отсутствующими данными с целью их сбора и ввода.
  5. ...

Исследование и обобщения

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

Наиболее важными с точки зрения записной книжки и «досье» будут следующие сведения.


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


Рост и вес

Названные показатели «впихнуты искусственно» и используются для обсуждения формата числовой информации. Именно поэтому они выделены на первое место.


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


Таблицы БД

Основным объектом будет человек (контакт), заносимый в нашу записную книжку. Соответственно, таблица в целом будет описывать некую совокупность людей, откуда следует обязательное множественное число в ее названии.

Люди

Закономерно, что эта таблица является главной.


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


Справочники

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

  1. Адреса.
  2. Телефонные номера разных типов.
  3. Почтовые серверы.
  4. Социальные сети.
  5. Мессенджеры.
  6. Можно ли обойтись без других? (Идет красной нитью через все занятия и большую часть текстов.)

Пока только здесь будет детально обсуждена тема справочников: назначение и общая структура. Дополнительную информацию можно найти также на странице Фамилия, имя и отчество (ФИО).

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


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


Телефонный номер

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


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


Таблица кодов стран

Без этой таблицы обойтись невозможно, так как у любого пользователя в какой-то момент появятся иностранные абоненты.

Записей в таблице будет немногим более 200. Но всё меняется, что ограниченно предусмотрено в ID.


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


Таблица-справочник типов телефонных номеров

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

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


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


Адреса

См. также Адреса.

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


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


Продолжение материала — в следующем разделе.

Адреса людей

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

Перечислим основные варианты адресов и связанные с ними ключевые особенности.


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


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

Таблица опять будет иметь примитивный характер.


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


Людей (главный объект) пока было немного, но пора завершать вопрос. Надеюсь, все уже догадались, что мы будем скрещивать коды людей и телефонов, которые пока повисли в воздухе.


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


....

Социальные сети и мессенджеры

Первое, что надо отметить — наличие двух видов названных ресурсов:


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


Родственные связи

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

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

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


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


Так как большинство случаев можно описать однозначно за счет абстрагирования от пола. Например, не «муж» и «жена», «супруг»; не «брат» и «сестра», а «брат/сестра».

При такой постановке, запросом

...man_id1=1 or man_id2=1

мы найдем всех родственников человека с ID=1, а запросом

...kin_id=1 and (man_id1=1 or man_id2=1)

его супруга (если этот kin_id соответствует 1).

Для определения пола и ФИО найденных персон в любом случае придется найти их в таблице людей.

Питомцы

Для чего может потребоваться такая информация?


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


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

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

Схема структуры БД

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


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


....

Сравнение таблицы в Excel и БД

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


Доступ к размещенным в этом месте материалам ограничен и предоставляется следующим категориям:
1. Студент I/II курса ВХК РАН.


Мы видим, что для единичной записи смысла в экономии практически нет. На самом деле всё много хуже, так как полноценно учесть справочники невозможно. Но для 1000 человек БД займет уже почти в 1,5 раза меньше места.


Из всего, изложенного в данном материале, должно следовать понимание того, сколь длинен, извилист и тернист путь разработки структуры таблиц БД.

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


Copyright © 1993–2024 Мацкявичюс Д.А. Все права защищены.
Никакая часть сайта не может быть воспроизведена никаким способом без письменного разрешения правообладателя и явной ссылки на данный ресурс.