Общесистемные требования и решения
Общесистемные требования и решения о реализуемости базы данных, как правило, формируются менеджером ИТ-проекта на основе анализа данных предметной области. Среди них наиболее важными для проектировщиков базы данных являются следующие требования и решения.
- Требования по аппаратно-программной платформе:
- тип компьютеров (Intel, SUN, HP и т.д.);
- топология сети и протоколы передачи данных (NetBIOS, TCP/IP и т. д.);
- тип операционной системы (MS Windows, Unix, OpenVMS и т.д.);
- архитектура базы данных ("клиент-сервер", параллельная архитектура);
- СУБД, на которой будет реализована база данных (MS SQLServer, Oracle, DB2 и т.д.);
- язык программирования или средства разработки приложений (C++, Delphi, MS VB и т.д.);
- Требования по обеспечению безопасности и разграничению доступа к базе данных;
- Требования по надежности работы базы данных;
- Требования по активности работы с данными:
- требования, позволяющие оценить объем базы данных;
- требования, позволяющие оценить интенсивность потока транзакций в системе;
- требования, позволяющие оценить пропускную способность сети;
- требования по максимально возможному числу активных пользователей базы данных;
- требования по актуализации данных;
- требования по производительности системы;
- требования по гибкости базы данных, т.е. открытость к модификациям структуры и кода.
Большинство перечисленных требований идут транзитом на следующие этапы процесса проектирования. Проектировщику базы данных на стадии планирования проектирования базы данных необходимо убедиться, что эти требования присутствуют в исходной документации, и в случае, если какие-либо требования отсутствуют, запросить их.
Рассмотрим некоторые примеры возможного неверного принятия решения по выбору СУБД. Предположим, что принято решение о разработке некоторой базы данных на СУБД Oracle. Закуплено и установлено оборудование. Однако информация об объеме базы данных и его потенциальном росте на этапе анализа требований к базе данных отсутствовала. База данных спроектирована и создана, готовится план тестирования приложений базы данных. При составлении плана тестирования базы данных выясняется, что в базе данных будет размещено 1000 записей длиной 100 байт, а рост числа записей базы данных оценивается как 10 записей в год! Базой данных будут пользоваться 4 раза в год для получения 5 видов отчетов. На производство всех отчетов за период требуется один день. Таким образом, цикл простоя системы будет много больше, чем время ее активной работы. В этом случае ответ на вопрос "А зачем выбрана промышленная СУБД Oracle?" имеет вполне экономический смысл.
Имеет место и обратная ситуация. Выбрали СУБД SQLBase. А через два года эксплуатации вышли на объем базы данных в 10 млн записей - цифра, характерная для финансовых подсистем крупного предприятия. И база данных "захлебнулась"!
Проектировщики баз данных! Будьте внимательны! Требуйте предоставления полного набора необходимой для принятия проектных решений информации!
