Рекомендации по созданию бд

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

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

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

Никогда не отвечайте пользователям отказом – просто объясните им, во что обойдется решение их вопроса. Разработайте стратегию развития архитектуры и инфраструктуры аппаратно - программных средств организации. Управляйте проектами, временем, технологиями, финансированием, взаимоотношениями с пользователями, инфраструктурой.

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

У разработчиков и пользователей нет общей цели. И те, и другие согласны, однако, что конечной целью ТЗ на БД должно быть выяснение, что именно должна выполнять БД.

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

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

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

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

• К началу разработки спецификации БД должен быть выработан документ со строгими рамками проекта;

• Функциональность БД должна быть реализована в виде отдельных подсистем;

• Необходимо разграничить подсистемы, ориентированные на выполнение различных этапов обработки: сбор, контроль, обмен данными и т.д.;

• Нужно попросить пользователей расположить все требования в порядке приоритета;

• Отвергнуть требования на те характеристики БД, которые не могут быть реализованы из-за неготовности техники или персонала (техническое вето);

• Отвергнуть характеристики, реализация которых приведет к большим затратам машинного времени, дискового пространства, и других ресурсов ЭВМ (операционное вето);

• Отвергнуть характеристики, если они не могут быть реализованы без нарушения временных ограничений на разработку (ресурсное вето).

Если БД становится перегруженной, то нужно срочно формулировать рекомендации по приведению ее в норму, вносить исправления в официальные документы проекта с обоснованием выполнимости и стоимости, а также требовать, чтобы пользователи одобрили эти изменения.

Выводы

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

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

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

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

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

Список литературы

1. Бойко В.В., Савинков В.М. Проектирование информационной базы на основе СУБД. – М.: Финансы и статистика. 1982. – 174 с.

2. Грекул В.И. Управление внедрением БД. - Интернет-университет информационных технологий - ИНТУИТ.ру 2008. Видеокурс. DVD-box: 2 диска.

3. Кайдалов А. Команда ИТ-проекта: как избежать проблем. [Электронный ресурс]. – Режим доступа: http://www.cnews.ru/reviews/articles/index.shtml?2005/06/20/180560_1, свободный. – Загл. с экрана.

4. Тиори Т., Фрай Дж. Проектирование структур БД. Кн. 1 и 2. - М.: Мир, 1985. Кн. 1. – 287 с.: Кн. 2. – 320 с.

5. Хансен Гэри, Хансен Джеймс. Базы данных: разработка и управление: Пер. с англ. - М.: ЗАО "Издательство БИНОМ", 1999. - 704 с.

Перечень вопросов для самопроверки

1. Как можно обеспечить надежность хранения данных?

2. Назовите проблемы создания БД

3. Какие этапы проектирования необходимо выполнить?

4. Какие требования должны выставляться к создаваемой БД?