Ссылочная страница на примеры разработки структур БД. Большая часть излагаемого здесь обсуждалось только на занятиях и никогда не было описано ни в одном литературном источнике. К сожалению, то что проговаривается в полулекции/полусеминаре продолжительностью 12–15 часов, достаточно трудоемко описывать в виде текста, это требует как времени, так и переработки.
В примерах будут достаточно подробно обсуждаться аргументация создания таблиц и полей, в том числе с принятием заведомо неверных решений и разбором последствий этих ошибок.
Не надо искать здесь готовых решений.
Крайне важно понять, что именно разработка структуры базы данных является ключевым этапом со всех точек зрения. Сложность этой работы заключается в том, что необходимо мысленное построение всего комплекса информационных единиц с выявлением точек их соприкосновения и формирования поисковых запросов. Процесс записи (оформления идей в виде структуры) до определенного момента лишь помогает сохранить наработанное. Достаточно серьезной ошибкой можно считать попытку реализации проекта в СУБД, что связано с невозможностью в обычно отводимое время "впихнуть" все действия, необходимые для получения реального продукта. Освоение навыков работы с избранными
Как показал большой опыт общения с программистами, неистребимой является идея создания собственной СУБД. Почему-то все дружно полагают, что десятилетия развития классов, функций и интерфейсов сотнями тысяч разработчиков могут быть "переплюнуты" единственным индивидуалом. Итогом становится глубокое незнание основ и вытекающее отсюда бесперспективное "изобретение велосипеда" с полной неспособностью правильно описать структуру. Рядовым же пользователям нужно научиться именно правильно формально видеть и разбирать информацию, правильно помочь вычислительной технике сделать работу за нас с вами.
Да, одним из самых интересных базовых информационных источников является Яндекс-маркет в режиме использования расширенного поиска со всеми параметрами. Зная, что многие из нас считают себя специалистами и обязательно плюнут на такой подход (либо кинут камень), сразу оговорюсь: на мой взгляд, большинство параметров собирается "по факту" их применения в описании товаров. Прежде чем говорить о невозможности или глупости того или иного параметра, просто попробуйте использовать его, поанализируйте – сильно удивитесь. Кроме того, любой информационный источник, приносящий хотя бы крохи пользы, бесценен с точки зрения разработчика БД.
Как уже было сказано выше, программист БД должен досконально разобраться с темой и стать своего рода "гиперпрофессионалом" в ней. Причем ему придется влезть в шкуру сразу нескольких категорий людей, тех, кто будет:
Всем перечисленным лицам должно быть всегда комфортно работать с создаваемым продуктом (ситуациями), но у каждого могут возникнуть свои личные и достаточно обоснованные потребности.
Итак, первым в дело вступит тот, кто будет собирать информацию
Приказы
Бланки
Можно смело сказать, что в основе процесса формирования структуры БД лежит разбор информации для ее занесения в справочники. В итоге, именно на них все и работает.
Более того, на уровне принятия решения о выделении той или иной информации в справочник или отказе от этого, мы задаем перспективы последующего развития БД. Переделка в будущем наверняка окажется чрезвычайно трудоемкой, так как затронет множество экранных форм и отчетов.
Эту категорию разумно выделить и описать сразу в связи с простотой структуры и важностью функционирования информационной системы.
С другой стороны, полноценный справочник может содержать десятки и сотни тысяч записей, найти и ввести информацию по которым достаточно сложно. Хотя проделана эта работа может быть независимо от ввода остальных данных.
С некоей долей условности, все справочники можно разделить на простые и сложные.
Самый простой справочник состоит всего из двух полей: id и наименования. Его назначение – помочь пользователю ввести информацию, а в последующем – найти ее, выбрав из списка.
Так как поле наименование часто используется для упорядоченного вывода на экран, оно должно быть проиндексировано.
Поле идентификатора, наоборот, постоянно используется для поиска нужного (уже внесенного в основной таблице) значения для вывода наименований, откуда также следует однозначная необходимость индексирования. Ведь от того, как быстро осуществляется частый поиск,
Нередко в справочники добавляются дополнительные показатели, а в ряде случаев справочник может стать универсальным информационным ресурсом, то есть базой данных, подключаемой к другим базам. В качестве примеров можно привести адреса; людей и, в частности, ФИО; перечень предприятий и т.д.
В связи с тем, что адреса используются достаточно часто, тема рассмотрена отдельно.
Интеграция с другим ПО
Изучение государственных и локальных нормативных документов
Оценка существующих, а, возможно, и используемых программных средств
Особенности устройст вывода (мониторы и принтеры)
Реорганизация процессов в том числе всего учета и производства. Очень часто на этапе исследования выявляется неадекватность, избыточность или недостаточность бумажного документирования событий.
Зачастую может возникнуть условная база знаний и решений ситуаций
Поля примечания для непредвиденных (неструктурируемых сейчас) записей.
Все перечисленное скручено в клубок с достаточно мощными обратными связями. Все всегда влияет на все. Программист обязан учитывать эти особенности на всех этапах разработки, но постараться выявить и учесть их до начала собственно работы, на этапе обследования.