hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

4.2 Стандарты именования для физической модели данных

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

Стандарт ISO/IEC 111791 призван обеспечивать упорядоченность семантики данных, пред ставления данных и регистрации описаний данных. Только с помощью этих описаний и можно точно понять доподлинное значение и смысловое содержание тех или иных данных. Важнейшей с точки имен, допустимых в физических реализациях БД, является «Часть 5. Принципы наимено вания и идентификация», которая описывает порядок выработки соглашений о наименованиях элементов данных и компонентов систем.

4.3 Использование сценариев для внесения любых изменений

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

5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ

5.1 Оценка готовности / Оценка рисков

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

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

1 ГОСТ Р ИСО/МЭК 11179-5-2012 Информационная технология (ИТ). Регистры метаданных (РМД).

250	Г Л А В А 6

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

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

5.2 Организационные и культурные изменения

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

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

Разработчики приложений часто видят в администраторах БД досадную помеху скорейшему завершению проектов, которая привносит дополнительные расходы без всякой видимой поль зы. АБД медленно принимают изменения в технологиях (XML, объектно- и сервис-ориентиро ванные архитектуры и т. п.) и новые методы разработки приложений (например, методологии Agile, Extreme Programming (XP) или Scrum). При этом разработчики, как правило, не осознают,

Хранение и операции с данными

251

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

Администраторы БД совместно с другими специалистами по управлению данными могут

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

исоблюдать описанные ниже правила.

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

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

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

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

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

252	Г Л А В А 6