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

Эта статья является продолжением моей предыдущей статьи, «Как пройти к третьей нормальной форме?».

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

Скрытый текст

Да что там студенты, есть уважаемые авторы учебников, которые сами перепрыгивают через этап концептуального моделирования! Понятно, что их учебники — про SQL, но какой пример студентам это даёт? Какую практику работы с базами данных они получат, если база данных, с которой предложено иметь дело, концептуально и близко не проработана? Вот пример структуры базы данных — 4 таблицы, ни одной связи:

Возьмём для примера определение концептуальной модели базы данных из Википедии:

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

Абсолютно точно, хорошо выверено многими поколениями разработчиков. Бери и пользуйся, правильно? Правильно, но не верно. Просто потому, что даже если объяснить студенту такие слова как «абстрактное», «высокоуровневое», «представление предметной области», «сущности», «атрибуты», «взаимосвязи», «требования пользователей», «ER-диаграмма», то это не означает, что студент, во-первых, поймёт всю концептуальность модели (а заодно и её отличия от других типов моделей), а во-вторых, сможет этим определением воспользоваться, чтобы реально построить такую модель базы данных. Тогда возникает вопрос: а как объяснять-то? Учтите ещё такую, казалось бы, мелкую, но немаловажную деталь: теория баз данных даётся на первом курсе, можно опираться только на «школьный» опыт студента и его знание предметных областей (в частности, незнание реальных бизнес-процессов предприятия), а также миропонимание соответствующего уровня.

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

Таким образом, построение концептуальных моделей становится процессом подсознательным и представляет собой интуитивный способ систематизации информации о той области, моделирование которой ведётся. У одних разработчиков с интуицией всё хорошо, и они успешно угадывают состав и хотя бы общий вид модели, тогда как у других на этом этапе возникают большие трудности и проблемы. Подливает масла в огонь и то, что для каких-то моделей (например, модель календаря или ежедневника) достаточно житейских знаний, для других же (система ведения бухгалтерского учёта, АСУ для управления технологическими процессами) необходимы широкие и глубокие знания из соответствующей области.

Давайте будем говорить начистоту: даже троечник может спроектировать работоспособную базу данных. Он просто сгребёт в кучу все сущности и распихает их параметры по таблицам по своему усмотрению, и такая база будет работать! Только вот с такой базой данных позже возникнут проблемы: она будет работать гораздо медленнее, чем могла бы, а её сопровождение (добавление функционала, выявление и исправление ошибок или какое-либо иное внесение изменений в структуру таблиц в ходе эксплуатации) превратится в филиал ада. Тогда возникает вопрос: чем работоспособная база данных отличается от эффективной? Определённо, своей структурой, и здесь кроется ещё один подводный камень, о котором практически не говорят даже в бизнес-анализе.

Ещё до начала проектирования структуры концептуальной модели важно определиться, что именно она будет описывать — состояние в каждый интересующий момент времени или каждое изменение, происходящее в системе? Существует довольно небольшое количество книг непосредственно по построению бизнес-моделей (не путать с бизнес-планированием и бизнес-анализом!), и их авторы как правило придерживаются одного из двух подходов (изучая это направление, не встретил ни одной книги, где автор, придерживаясь одного из подходов, хотя бы упомянул второй). Первый предполагает описание состояний каждого элемента системы (в производстве столько-то изделий, процент готовности такой-то, количество сырья и готовой продукции на складе такое-то): это удобно для управления системой, в которой важны индикаторы текущего состояния (как температура воды и давление масла в двигателе) — если наблюдаем какое-то отклонение, меняем воздействие на систему. Второй предполагает описание изменений (на склад поставлено, со склада отправлено в магазин, сырьё в таком-то количестве передано в производственный цех, из цеха получено столько-то единиц такой-то продукции) — это удобно для управления по результатам, чтобы сравнивать полученный результат с вложенными ресурсами (усилиями). При этом подходе важно помнить, что учитываются не состояния системы, а их «перещёлкивания»: вот деньги были на счёте, а вот какой-то суммы нет, но есть задолженность поставщика на эту же сумму, или вот товар был на складе, а сейчас он в кузове автомобиля отдела доставки.

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

Объединение подходов допустимо, но практикуется редко (поскольку оно привнесёт в модель усложнение её для понимания): в таком случае один будет преобладать, а данные для второго подхода будут вычисляться из информации, которой оперируем в рамках первого. Например, нам важно, сколько денег в каждый конкретный момент времени есть на счёте — тогда любая операция со счётом может быть вычислена как разность между двумя состояниями — «до» и «после» (не очень удачный вариант, поскольку в один момент может пройти две операции, и мы их не разделим, более того, они могут вызывать диаметрально противоположные денежные потоки, и мы вообще не увидим изменений, так что такие «мелочи» тоже нужно обнаруживать на начальных этапах проектирования). Однако, применив в этом же случае подход, предполагающий учёт изменений, мы начнём фиксировать именно их, тогда будут вычислены уже состояния системы в нужные моменты времени.

Описывая базу данных для заданной предметной области информационной системы, мы также должны принимать во внимание, что взаимодействие этой системы с пользователем — это не просто перебрасывание циферок с клавиатуры в машину и из машины на экран, а своего рода рассказывание историй. Какие-то из этих историй имеют второстепенный смысл и малозначимы (например, грузчику Иванову выдана пара рабочих рукавиц — с точки зрения бизнеса в целом это малозначимый факт), другие отражают всю суть моделируемой системы (например, в прошлом месяце бизнес заработал 100 миллионов выручки, но при этом потратил 105 миллионов — Х… (шум в эфире), у нас проблемы!).

То есть, если самой главной «историей», которую рассказывает пользователю база данных, является история зарабатывания прибыли, то от этого показателя и нужно отталкиваться, «разворачивая» её в более мелкие и подробные истории. Что влияет на прибыль? Расходы и доходы. Что влияет на расходы? Наличие или, наоборот, отсутствие тех или иных статей затрат и их величина. Что влияет на само наличие конкретной статьи затрат? а на её величину? Задавая такие вопросы, мы не просто собираем фактуру, не просто выписываем те или иные показатели, которые впоследствии лягут (или нет) в основу базы данных, но и определяем их значимость с точки зрения конкретного результата. Например, выдача пары рабочих рукавиц грузчику Иванову очень мало повлияла на превышение затрат над доходами бизнеса (да совсем никак), и большой вопрос — нужно ли детализировать модель до такой степени, чтобы она начала учитывать даже такие мелочи (хотя иногда приходится, например в бухучёте — потеряете копеечку, долго искать будете).

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

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

Студенту важно знать:

1. в какой день какой парой в каком кабинете какие занятия стоят у его группы

2. где и в какое время можно найти того или иного преподавателя, если к нему возникнут какие-то вопросы (например, организационного характера)

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

Преподавателю важно знать:

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

2. сколько часов по какому предмету преподаватель уже провёл (важно, чтобы контролировать продвижение по плану изучения предмета и ориентироваться в том, какая тема будет на следующем занятии, плюс опять же — если преподаватель не контролирует номера занятий, он будет попадать в ситуацию, когда на прошлой неделе было занятие — и оно, оказывается, было последним в курсе, а зачётные задания студенты ещё не делали)

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

Диспетчеру важно знать:

1. где можно найти в конкретный момент времени такую-то группу / преподавателя / свободную аудиторию — такой вопрос часто возникает, когда приходит команда провести очередное мероприятие в таких-то группах

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

3. сколько часов по каким предметам выдано у той или иной группы или тем или иным преподавателем (если производственные практики стоят в середине учебного года, критически важно правильно спланировать нагрузку студентов и преподавателей, чтобы ничего не упустить у одних и равномерно распределить на весь учебный год нагрузку у других, чтобы не было, например, ситуации, когда у выпускной группы какие-то предметы забыли поставить в расписание, или ситуации, когда у преподавателя в первом семестре диспетчер ставит по 60 часов в неделю при нагрузке на ставку 18, а на второй семестр у преподавателя остаётся 200 часов на 25 недель, и уже с марта он вообще не появляется на работе, поскольку всё выдал)

Администрация обычно интересуется общей нагрузкой преподавателей и её выполнением, возможно, ещё какими-то вопросами, касающимися студентов (не вдавался в детали их работы).

Каждая из этих историй в итоге превратится в запрос SQL или их цепочку. У студентов самый большой ступор — в том, чтобы обнаружить эти истории и корректно их описать (с дальнейшей формализацией проблем обычно не возникает). В основном все проблемы связаны с тем, что студенты не имеют соответствующего жизненного опыта и знания бизнес-процессов (или имеют представление о них, крайне удалённое, оторванное от реальности), и если преподаватель им не подскажет, «куда и на что смотреть» и как оно всё устроено, то на выходе получатся сферические кони в вакууме высотой один метр и массой 1 кг, хранящиеся в Париже, в палате мер и весов. Постановка задачи преподавателем играет решающую роль, импровизации возможны, но они всегда требуют многократно большей подготовки.

Ещё одна проблема заключается в том, что все люди разные. Одним подавай чёткие формулировки, они их поймут запомнят, и пойдут дальше. Таких людей мало (один-два человека из сотни студентов), они зачастую умеют и любят приводить всё к формализованному виду, возможно, считая, что только то, что хорошо формализовано, то и может быть понято, то есть встроено в собственную систему представлений мира. Система формулировок для них превращается в систему непреложных законов, по которым человек начинает функционировать (как машина? возможно), и любая попытка взглянуть на формулировку с другой стороны ломает картину мира, против чего носитель этой картины мира, естественно, неистово протестует. Есть люди, которым недостаточно запомнить (вызубрить) определение, чтобы встроить его в своё миропонимание — нужны какие-то хорошо знакомые образы, уже существующие в памяти, к которым можно «прицепить» новые знания. Кто-то старается логически связать новые знания с уже имеющимися (и горе ему, если имеющиеся знания начинают противоречить новой теории — у человека опять-таки рушится картина мира!). Есть и те, кто какие-то новые знания «цепляет» к образам, другие — связывает логически, третьи просто вызубривает, просто чтобы можно было ими пользоваться — такая гибкость менее энергозатратна и помогает максимально расширить свою картину мира, хотя тоже не лишена проблем (невозможность И доказать, И описать абсолютно всё, что у человека лежит в основе его миропонимания).

Так вот, в образовании нет и не может быть единого «правильного» подхода к обучению всех подряд — даже в рамках отдельно взятой темы. Разным людям нужно объяснять одну и ту же тему по-разному, «заходя на цель» с разных сторон. Поэтому, читая статьи, написанные преподавателями, прежде чем кинуть в них тапком, подумайте — не пытаются ли они показать знакомый вам предмет немножечко с другой стороны, не с той, что удобна и привычна вам? Спорьте с преподавателями, это развивает и вас, и их, не говоря уже про то, что в споре рождается истина. Но в споре постарайтесь не задавить авторитетом (как правило, чужим, разработанным кем-то другим шаблоном), а для начала понять, что именно имел в виду автор, и где именно (возможно) его теория не сработает.