Основные  данные о работе

     Содержание

     Введение

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

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

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

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

     Концептуальное  проектирование базы данных. Конструирование информационной модели предприятия, не зависящей от каких-либо физических условий реализации. [1, С.110]

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

     Логическое  проектирование базы данных заключается в преобразовании концептуальной модели данных в логическую модель данных предприятия с учетом выбранного типа СУБД (например, предполагается использование некоторой реляционной СУБД). Логическая модель данных является источником информации для этапа физического проектирования. Она предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет исключительно важное значение для выбора действительно эффективного проектного решения. [1, С.130]

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

     1 Проектирование баз данных

     1.1 Общее определение методологии проектирования

     Методология концептуального и логического  проектирования базы данных связана  с физическим проектированием.

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

     Методология проектирования предусматривает разбиение  всего процесса на несколько стадий, каждая из которых, в свою очередь, состоит из нескольких этапов. На каждом этапе разработчику предлагается набор технических приемов, позволяющих решать задачи, стоящие перед ним на данной стадии разработки. Кроме того, методология предлагает методы планирования, координации, управления, оценки хода разработки проекта, а также структурированный подход к анализу и моделированию всего набора требований, предъявляемых к базе данных, и позволяет выполнить эти действия стандартизированным и организованным образом. [2, С.89]

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

     Физическое  проектирование базы данных предусматривает  принятие разработчиком окончательного решения о способах реализации создаваемой  базы. Поэтому физическое проектирование обязательно производится с учетом всех особенностей используемой СУБД. Между этапами физического и логического проектирования всегда имеется определенная обратная связь, поскольку решения, принятые на этапе физического проектирования с целью повышения производительности разрабатываемой системы, могут потребовать определенной корректировки логической модели данных. [2, С.178]

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

• Поддерживать постоянную и активную связь с будущими пользователями приложения.
• При проведении процедур моделирования данных придерживаться обоснованной методологии.
• Применять подходы, предусматривающие создание приложений, управляемых данными.
• Создавать модель данных с учетом требований поддержки их структурной целостности и согласованности.
• В процессе реализации методологии моделирования данных применять методы разработки концептуальной модели, нормализации и проверки целостности транзакций.
• Для представления модели данных как можно шире использовать схемы.
• Для описания дополнительных семантических требований к данным использовать средства языка проектирования баз данных (Database Design Language — DBDL).
• В дополнение к схемам моделей данных и конструкциям DBDL разрабатывать словарь описания данных.

     1.2  Важнейшие факторы  успешного проектирования  базы данных

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

• Поддерживайте постоянную и активную связь с будущими пользователями приложения.
• При проведении процедур моделирования данных придерживайтесь обоснованной методологии.
• Применяйте подходы, предусматривающие создание приложений, управляемых данными.
• Создавайте модель данных с учетом требований поддержки их структурной целостности и согласованности.
• В процессе реализации методологии моделирования данных применяйте методы разработки концептуальной модели, нормализации и проверки целостности транзакций.
• Для представления модели данных как можно шире используйте схемы.
• Для описания дополнительных семантических требований к данным используйте средства языка проектирования баз данных (Database Design Language — DBDL).
• В дополнение к схемам моделей данных и конструкциям DBDL разработайте словарь описания данных.

     Первой  фазой проекта разработки ХД является бизнес-анализ  процессов и данных предприятия. В России,  несмотря  на  широкое  распространение  CASE-технологии, к  бизнес-анализу  и  проектированию  данных  на  концептуальном уровне не всегда относятся достаточно серьезно (Основные стадии построения хранилища данных описаны в Приложении 1). Между тем относительно  СППР на основе  ХД  можно  с  уверенностью  утверждать,  что  ее  разработка  без подобного  анализа  заранее  обречена  на  неудачу.  Без  ясного   понимания разработчиками целей бизнеса, способов их достижения, возникающих  при  этом проблем и методов их решения, ресурсы, необходимые для разработки ХД,  будут потрачены зря. Самым критичным из ресурсов сейчас  является  время,  и  тот, кто начал разработку СППР, не определив заранее, кто,  когда,  зачем  и  как будет принимать решения, какое влияние то  или  иное  решение  оказывает  на бизнес, какие решения отнести к оперативным, а какие к стратегическим  и  т.д., обрекает себя на неизбежное отставание в конкурентной борьбе. [3, С.101]

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

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

     Иными словами, бизнес-событие является более устойчивым и более тесно связанным с информационными и управляющими потоками  понятием,  чем  бизнес- процесс.

     Через  анализ  бизнес-событий  необходимо  перейти  к  анализу  данных, используемых предприятием.  При  этом  должна  быть  собрана  информация  об используемых  внешних  данных  и их   источниках;   о   форматах   данных, периодичности и форме их поступления; о внутренних  информационных  системах предприятия, их функциях и алгоритмах  обработки  данных,  используемых  при наступлении бизнес-событий. Такой  анализ,  как  правило,  производится  при проектировании любой информационной системы. Особенность анализа данных  при проектировании СППР на основе ИХ состоит в  необходимости  создания  моделей представления  информации.  То,  что  в  транзакционных  системах   является вторичным понятием, а именно состав и форма отображаемых  данных,  в СППР приобретает особую важность,  так  как нужно  выявить  все  без  исключения признаки, требуемые для менеджерского состава. [4, С.311]

     При проектировании транзакционной системы обычно строго  выдерживается последовательность процессов: бизнес-анализ, концептуальная  модель  данных, физическая  модель  данных,  структура  интерфейса  и  т.  п. Возврат   на предыдущий уровень происходит редко и считается отклонением  от  нормального хода выполнения проекта. В случае СППР на  основе  ХД  нормальным  считается итерационный, а иногда и параллельный, характер моделирования,  при  котором возврат  на  предыдущую  стадию - обычное явление.   Это связано с необходимостью выделения всех требуемых  данных  для  произвольных  запросов (ad-hoc), для чего  следует  составить  исчерпывающий  перечень  необходимых данных и построить схему их связей через бизнес-события. При этом из  общего массива  выделяется  значимая  информация   и   выясняется   потребность   в дополнительных источниках данных для принятия решений. [5, С.231]

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

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

     2 Общий обзор этапов проектирования базы данных