Определение требований к системе

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

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

Главные задачи при определении требований к системе

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

• определение целей создания системы;

• определение объема и типов данных;

• определение способов использования данных;

• определение бизнес-правил.

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

Определение целей создания системы

Проектирование базы данных требует понимания моделируемых ею бизнес-функций.

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

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

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

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

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

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

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

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

Определение объема и типов данных

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

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

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

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

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

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

Определение способов использования данных

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

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

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

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

Определение бизнес-правил системы

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

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

Дата добавления: 2014-01-11