Техническая библиотека CITForum.ru CITKIT.ru - все об Open Source Форумы Курилка
Все новости / Все статьи Деловая газета - шквал(!) IT-новостей :: CITCITY.RU
Первая полоса ИТ-Инфраструктура Телекоммуникации Безопасность BI Интеграционные платформы КИС IT-бизнес Ширпотреб Точка зрения

29.06.2017

Новости:


Все новости

КИС :: Управление проектами

Описание структуры БД: роскошь или необходимость?

Модель базы данных

При автоматизации процессов ITSM (IT Service Management) одним из основных факторов, определяющих успешность проекта, является структура базы данных внедряемой системы. Структура БД может быть представлена в виде моделей данных различного уровня. В данной статье речь будет идти о следующих:
  • Концептуальная модель данных — записанные знания о физических и логических объектах реального мира (люди, компоненты инфраструктуры, наряды на работу, договора, соглашения и т. д.), которыми необходимо управлять наиболее рациональным образом.
  • Логическая модель данных — описание объектов предметной области, их атрибутов и взаимосвязей между ними в том объеме, в котором они подлежат непосредственному хранению в базе данных системы. Строится на основе концептуальной модели данных.
  • Физическая модель данных — способ хранения данных в конкретной СУБД. Строится на основе логической модели данных.

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

Как же оценить качество модели данных и функциональности, предназначенной для работы с ней? Для этих целей можно использовать набор критериев PinkVerify, разработанный организацией Pink Elephant (участницей разработки методологии ITIL) специально для самостоятельной оценки системы автоматизации процессов ITSM. Критерии эти предназначены для оценки совместимости структуры системы автоматизации с методологией ITIL и распространяются бесплатно (www.pinkelephant.com).

Для чего нужно описание структуры БД?

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

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

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

  1. Выбор организацией-заказчиком системы автоматизации.
  2. Подготовка и настройка системы автоматизации организацией-интегратором.
  3. Взаимодействие заказчика и интегратора в ходе внедрения системы автоматизации.
  4. Взаимодействие заказчика и интегратора по вопросам поддержки системы автоматизации.

В каждой области описание структуры БД обеспечивает свои преимущества. Рассмотрим их подробно.

  1. Выбор организацией-заказчиком системы автоматизации
    Преимущества:
    • возможность оценки всех аспектов системы, полнота информации
    • удобство анализа предлагаемой системы сотрудниками организации-заказчика
    Возможности системы автоматизации определяются ее моделью данных. В среднем 60% времени анализа одного коммерческого предложения прямо или косвенно тратится на оценку именно модели данных системы. Подробное описание не только функциональности системы, но и структуры БД позволяет потенциальному клиенту осуществить комплексный обзор возможностей системы, оперировать всей необходимой информацией и создает значительное конкурентное преимущество компании-интегратору. Отсутствие же описания структуры БД с большой вероятностью приведет к вынесению отрицательного решения по системе и, скорее всего, по интегратору, ее предлагающему, — невозможность составления законченного представления о возможностях системы серьезно снижает общее впечатление о потенциальном исполнителе проекта.
  2. Выполнение настройки и внедрение системы автоматизации организацией-интегратором
    Преимущества:
    • упрощение логического проектирования процессов
    • упрощение настройки системы
    • упрощение разработки интеграции с другими системами
    За редким исключением, в организациях-интеграторах доля сотрудников, имеющих представление о модели данных системы, невелика. Особенно если клиентам предлагается система автоматизации сторонних производителей. Ситуации же, в которых сотрудникам, не связанным с проектированием и разработкой БД, требуется информация о логической или физической модели данных, возникают довольно часто. Информационный вакуум, образующийся вследствие отсутствия или сложности использования источника такой информации, ведет к возникновению узких мест в работе команды проекта — потребности в информации не могут быть оперативно удовлетворены. Если же любой сотрудник может получить необходимые ему сведения самостоятельно, то подобных узких мест не возникает — работа всей команды становится более слаженной, качественной и эффективной. Упрощается работа бизнес-аналитиков, технических специалистов, настраивающих систему и проектирующих интеграцию, а также взаимодействие между ними.
  3. Взаимодействие организаций заказчика и интегратора в ходе внедрения системы автоматизации
    Преимущества:
    • ускорение обучения и понимания сотрудниками организации-заказчика особенностей работы с внедряемым инструментарием
    • увеличение конечной системы прозрачности
    • увеличение эффективности приемочного тестирования (опытной эксплуатации)
    Успешность внедрения системы, автоматизирующей процессы ITSM, равно как и сложность осуществления этого процесса, зависит от множества факторов. Одним из ключевых является уровень взаимопонимания между сотрудниками заказчика и исполнителя. Качественное описание модели данных позволяет исполнителю найти «общий язык» с заказчиком по вопросам, связанным с системой автоматизации и ее эксплуатацией. И чем быстрее будет найден такой язык, тем быстрее и легче будет проходить обучение пользователей, тем больше у них останется времени, чтобы вникнуть в особенности работы с внедряемым инструментарием, тем эффективнее пройдет опытно-промышленная эксплуатация и самые серьезные проблемы будут решены до окончательной сдачи системы.
  4. Взаимодействие организаций заказчика и интегратора по вопросам поддержки системы автоматизации
    Преимущества:
    • увеличение количества проблем, устраненных заказчиком самостоятельно
    • облегчение взаимопонимания при описании проблем
    • увеличение скорости устранения проблем
    Если взаимоотношения заказчика и исполнителя не ограничиваются рамками одного проекта и обе организации нацелены на длительное сотрудничество, то четкое описание модели данных системы позволяет сгладить многие острые углы и значительно упростить коммуникации на уровне технических специалистов. Обладая полной информацией о базе данных, администраторы системы со стороны заказчика в большинстве случаев в состоянии самостоятельно устранить ошибки данных, хранящихся в БД, избегая потерь времени на объяснение проблемы представителям организации-интегратора. Если же ситуация все-таки требует вмешательства специалистов интегратора, то знание логической и физической моделей представителями обеих сторон позволяет существенно сократить время, затрачиваемое на выяснение деталей возникшей ошибки. При устранении же проблемы специалистами интегратора описание структуры БД позволяет увеличить скорость обработки заявки, так как предоставляет заинтересованным лицам необходимую информацию по объектам и таблицам системы, что становится особенно полезным по прошествии некоторого времени с момента внедрения.

Как описывать структуру БД?

Как же описать структуру БД, чтобы максимальное количество упомянутых выше преимуществ стало ощутимым? Требования к документу, описывающему базу данных системы автоматизации, можно объединить в следующие направления:
  • Структура документа
  • Информация об объекте и таблице
  • Оформление документа
  1. Структура документа
    Документ должен описывать как логическую, так и физическую модели. В большинстве систем автоматизации эти модели практически совпадают, поэтому вполне можно обойтись перечнем таблиц, для каждой из которых указывается название типа объекта, в ней хранящегося. Однако в некоторых системах логическая и физическая модели существенно отличаются. Происходит это по следующим причинам:
    • Некоторые таблицы хранят несколько типов объектов
    • Атрибуты одного типа объекта хранятся в нескольких таблицах
    • Объекты имеют много логических атрибутов, то есть их значения не хранятся сами по себе, а являются результатом агрегации данных из других таблиц
    В таких случаях описание структуры БД должно содержать два раздела:
    • Перечень типов объектов, их атрибутов и взаимосвязей
    • Перечень таблиц БД, их состав и взаимосвязи
    К документу может быть приложена графическая схема объектов и/или таблиц системы. Однако создание такой схемы, если оно не происходит автоматически, крайне трудоемко и не всегда целесообразно — при больших количествах таблиц и объектов схема теряет смысл, так как трудно воспринимается пользователем. Таким образом, включение схем объектов/таблиц в описание структуры БД имеет смысл только в случае относительно простых систем.
  2. Информация о таблицах и объектах
    От полноты информации, предоставляемой по каждой таблице БД и по каждому типу объектов, зависит ее полезность для пользователя системы. Описание типа объектов эффективнее организовать в виде перечня атрибутов объекта данного типа, а описание таблицы — в виде списка полей. Перечень атрибутов объекта должен содержать следующую информацию о каждом атрибуте:
    • Наименование атрибута
    • Описание атрибута
    • Формат данных
    • Наименование таблицы и столбца, хранящего значение атрибута
    • Перечень взаимосвязей (как с объектами, так и с таблицами)
    Список полей таблицы должен описывать каждое поле следующим образом:
    • Наименование поля
    • Тип данных
    • Признак обязательности заполнения
    • Наименование объекта и атрибута, значение которого хранится в данном поле
    • Перечень взаимосвязей (с таблицами)
    Кроме того, для каждого типа объекта должен быть приведен перечень таблиц, хранящих значения атрибутов объектов этого типа, а для каждой таблицы — перечень типов объектов, значения атрибутов которых в ней хранятся.
  3. Оформление документа Разумеется, конкретные варианты оформления документации зависят от внутренних стандартов организации. Однако практика показывает, что неотъемлемым признаком легкого для восприятия и удобного для использования в электронном виде документа является оформление упоминаний объектов и таблиц БД в виде перекрестных ссылок. Применение перекрестных ссылок существенно упрощает работу с документом — навигация по объектам и таблицам и поиск интересующей информации становятся быстрыми и целенаправленными.

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

Какое место занимает описание структуры БД в проектной документации?

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

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



IT News

Комментарии

Страницы комментариев: предыдущая :: 1 :: 2

аноним, Mon Oct 29 09:32:19 2007:
Утеряны старые традиции советских времен, клогда наши програмисты ценились за системный подход и умение документировать.
Это точно.
аноним, Thu Oct 18 12:19:59 2007:
Евгений, вам что-то непонятно из написаного? Мой элементарный русский язык ничуть не хуже вашего элементарного. Так что лучше по существу.
Евгений, Thu Oct 18 11:24:03 2007:
Кирилл, как Вы можете рассуждать о логических и концептуальных моделях БД если Вы не знаете элементарного русского языка, не имеете представления о том "понимание работы сервера БД" очень даже в моде и зарплаты в этой области очень даже не падают.
Кирилл, Mon Aug 20 17:26:58 2007:
...Поэтому куда эффективней хорошую презентацию продукта сделать, чем структура БД описывать и на документацию тратиться.
Кирилл, Mon Aug 20 17:24:09 2007:
Алекс, дело наверное в том, что столь глубокая документация дорого обходиться и мало добавляет с маркетинговой точки зрения. Кто на стороне потребителя будет разбираться в хитросплетениях модели? Подавляющее большинство и разработчиков и вредренцев всё равно о БД знают только, что "это такая штука, где данные хранятся" и краем уха слышали о простейших конструкциях SQL. Чтоб оценить оптимальность физической модели, мне кажется, нужно глубоко понимать работу целевого сервера БД, а сейчас это не в моде, слишком много времени тратиться, по сути, впустую. Конкуренция велика, зарплаты в этой области падают, качество падает ещё сильнее.
Алекс, Fri Aug 17 16:08:37 2007:
По описанию базы данных вполне можно определить степень ее оптимальности.
Вопрос только по каким критериям оценивать.
Но концептуальная, логическая и физическая модель позволяют это делать.
В последнее время существует тенденция вообще ничего не описывать и не создавать документов к системам. Утеряны старые традиции советских времен, клогда наши програмисты ценились за системный подход и умение документировать.
Кирилл, Wed May 23 16:03:53 2007:
К сожалению, наличие описания структуры БД мало соотносится с возможоностью делать выводы об оптимальности БД. Хотя, конечно, это не значит, что описание БД делать не стоит. Ведь этот артефакт всё равно в процессе разработки формируется, так что почему б не ознакомить с ним потребителя или интегратора. Но не стоит забывать -- в современных Н-звеньевых объектно-ориентированных архитектурах БД с уровнем логики часто очень сложно и хитро взаимодействует, и надо иметь немалый талант и умение, чтоб доходчиво (хотя бы для грамотных специалистов) представить замысел разработчиков (если конечно они сами этот замысел до конца понимают :)).

Страницы комментариев: предыдущая :: 1 :: 2

Комментарии заморожены.

Последние комментарии:

Самое интересное:


© 2004–2009 Проект CITCITY.ru