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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приказы....

Бланки....

Справочники

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

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

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

....

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

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

....

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

Адреса в БД

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

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

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

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

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