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

Возим из Питера piter-gruzoperevozki.ru грузоперевозки во Владивосток.          

Общесистемные требования и решения


Общесистемные требования и решения о реализуемости базы данных, как правило, формируются менеджером ИТ-проекта на основе анализа данных предметной области. Среди них наиболее важными для проектировщиков базы данных являются следующие требования и решения.

  • Требования по аппаратно-программной платформе:
    • тип компьютеров (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 млн записей - цифра, характерная для финансовых подсистем крупного предприятия. И база данных "захлебнулась"!

Проектировщики баз данных! Будьте внимательны! Требуйте предоставления полного набора необходимой для принятия проектных решений информации!



Содержание раздела