Базы данных: примеры

Ссылочная страница на примеры разработки структур БД. Большая часть излагаемого здесь обсуждалось только на занятиях и никогда не было описано ни в одном литературном источнике. К сожалению, то что проговаривается в полулекции/полусеминаре продолжительностью 12–15 часов, достаточно трудоемко описывать в виде текста, это требует как времени, так и переработки.

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

Не надо искать здесь готовых решений.

Крайне важно понять, что именно разработка структуры базы данных является ключевым этапом со всех точек зрения. Сложность этой работы заключается в том, что необходимо мысленное построение всего комплекса информационных единиц с выявлением точек их соприкосновения и формирования поисковых запросов. Процесс записи (оформления идей в виде структуры) до определенного момента лишь помогает сохранить наработанное. Достаточно серьезной ошибкой можно считать попытку реализации проекта в СУБД, что связано с невозможностью в обычно отводимое время «впихнуть» все действия, необходимые для получения реального продукта. Освоение навыков работы с избранными направлениями и единичной СУБД не породит ничего, кроме абсолютно необоснованной уверенности понимания тематики.

Как показал большой опыт общения с программистами, неистребимой является идея создания собственной СУБД. Почему-то все дружно полагают, что десятилетия развития классов, функций и интерфейсов сотнями тысяч разработчиков могут быть «переплюнуты» единственным индивидуалом. Итогом становится глубокое незнание основ и вытекающее отсюда бесперспективное «изобретение велосипеда» с полной неспособностью правильно описать структуру. Рядовым же пользователям нужно научиться именно правильно формально видеть и разбирать информацию, правильно помочь вычислительной технике сделать работу за нас с вами.

    Ниже приведены рассуждения по разработке структур БД по нескольким темам.
  1. Разбор обычной таблицы в базу данных (тривиальный подход из учебников).
  2. Записная книжка.
  3. Склад автозапчастей.
  4. Библиографические источники (книга и статья).

Да, одним из самых интересных базовых информационных источников является Яндекс-маркет в режиме использования расширенного поиска со всеми параметрами. Зная, что многие из нас считают себя специалистами и обязательно плюнут на такой подход (либо кинут камень), сразу оговорюсь: на мой взгляд, большинство параметров собирается «по факту» их применения в описании товаров. Прежде чем говорить о невозможности или глупости того или иного параметра, просто попробуйте использовать его, проанализируйте — сильно удивитесь. Кроме того, любой информационный источник, приносящий хотя бы крохи пользы, бесценен с точки зрения разработчика БД.

Типовые ошибки при разработке структуры


Доступ к этим материалам предоставляется только зарегистрированным пользователям!


Необходимые вводные условия, исследование темы

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


Доступ к этим материалам предоставляется только зарегистрированным пользователям!


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

Итак, первым в дело вступит тот, кто будет собирать информацию

Приказы...

Бланки...

Справочники

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

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

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

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

С некоей долей условности, все справочники можно разделить на простые и сложные.

Самый простой справочник состоит всего из двух полей: id и наименования. Его назначение — помочь пользователю ввести информацию, а в последующем — найти ее, выбрав из списка.

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

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

...

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

Адреса в БД

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

Дополнительные тезисы

Интеграция с другим ПО.

Изучение государственных и локальных нормативных документов.

Оценка существующих, а, возможно, и используемых программных средств.

Особенности устройств вывода (мониторы и принтеры).

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

Зачастую может возникнуть условная база знаний и решений ситуаций.

Поля примечания для непредвиденных (неструктурируемых сейчас) записей.

Все перечисленное скручено в клубок с достаточно мощными обратными связями. Всё всегда влияет на всё. Программист обязан учитывать эти особенности на всех этапах разработки, но постараться выявить и учесть их до начала собственно работы, на этапе обследования.


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