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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


курсовая работа Физическое проектирование баз данных

Информация:

Тип работы: курсовая работа. Добавлен: 23.08.2012. Сдан: 2012. Страниц: 6. Уникальность по antiplagiat.ru: < 30%

Описание (план):


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

 
Версия  шаблона 1.1
Филиал  
Вид работы Курсовая работа
Название  дисциплины Базы данных
Тема Физическое  проектирование баз данных
Фамилия студента  
Имя студента  
Отчество  студента  
№ контракта  

     Содержание

     Введение

 
     Основные  этапы жизненного цикла приложения базы данных является проектирование базы данных. Оно начинается по завершении анализа всех требований к проекту, выдвигаемых со стороны предприятия-заказчика.
     Методология, предлагаемая для проектирования базы данных, входящей в общий жизненный цикл приложения, использующего базы данных реляционного типа. Предлагаемая методология представляет собой поэтапное руководство, охватывающее три основных этапа проектирования баз данных: концептуальное, логическое и физическое проектирование.
     Физическое  проектирование — создание концептуального представления базы данных, включающее определение типов важнейших сущностей и существующих между ними связей и атрибутов.
     В предлагаемой методологии весь процесс проектирования базы данных подразделяется на три основных этапа: концептуальное, логическое и физическое проектирование.
     Концептуальное  проектирование базы данных. Конструирование информационной модели предприятия, не зависящей от каких-либо физических условий реализации. [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 Общий обзор этапов проектирования базы данных

 
     В целом процедура разработки включает следующие этапы:
     Концептуальное  проектирование базы данных
    Создание локальной концептуальной модели данных исходя из представлений о предметной области каждого из типов пользователей.
    Определение типов сущностей.
    Определение типов связей.
    Определение атрибутов и связывание их с типами сущностей и связей.
    Определение доменов атрибутов.
    Определение атрибутов, являющихся потенциальными и первичными ключами.
    Обоснование необходимости использования понятий расширенного моделирования (необязательный этап).
    Проверка модели на отсутствие избыточности.
    Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.
    Обсуждение локальных концептуальных моделей данных с конечными пользователями.
       Логическое  проектирование базы данных (для реляционной  модели)
    Создание и проверка локальной логической модели данных на основе представления о предметной области каждого из типов пользователей.
    Устранение особенностей локальной логической модели, несовместимых с реляционной моделью (необязательный этап).
    Определение набора отношений исходя из структуры локальной логической модели данных.
    Проверка отношений с помощью правил нормализации.
    Проверка соответствия отношений требованиям пользовательских транзакций.
    Определение требований поддержки целостности данных.
    Обсуждение разработанных локальных логических моделей данных с конечными пользователями.
    Создание и проверка глобальной логической модели данных.
    Слияние локальных логических моделей данных в единую глобальную модель данных.
    Проверка глобальной логической модели данных.
    Проверка возможностей расширения модели в будущем.
    Обсуждение глобальной логической модели данных с пользователями.
 
       Физическое  проектирование базы данных (с использованием реляционной СУБД)
    Перенос глобальной логической модели данных в среду целевой СУБД.
    Проектирование базовых отношений в среде целевой СУБД.
    Проектирование отношений, содержащих производные данные.
    Реализация ограничений предметной области.
    Проектирование физического представления базы данных.
    Анализ транзакций.
    Выбор файловой структуры.
    Определение индексов.
    Определение требований к дисковой памяти.
    Разработка пользовательских представлений.
    Разработка механизмов защиты.
    Анализ необходимости введения контролируемой избыточности.
    Организация мониторинга и настройка функционирования операционной системы.
     Концептуальное  и логическое проектирование базы данных включает три основных этапа. Задачей первого этапа является разбиение проекта на группу относительно небольших (и более простых) задач исходя из представлений о предметной области приложения, свойственных каждому из типов конечных пользователей. Результатом выполнения этого этапа является создание локальных концептуальных моделей данных, представляющих собой полное и точное отражение представлений о предметной области приложения отдельных типов пользователей. [6, С.99]
     На  втором этапе локальные концептуальные модели данных преобразуются в локальные логические модели данных (для реляционной модели данных), состоящие из ER-диаграммы, реляционной схемы и сопроводительной документации. Затем корректность логических моделей данных проверяется с помощью правил нормализации. Нормализация представляет собой эффективное средство, позволяющее убедиться в структурной согласованности, логической целостности и минимальной избыточности принятой модели данных. Дополнительно модель данных проверяется с целью выявления возможности осуществления транзакций, которые будут выполняться пользователями создаваемого приложения. Все эти проверки позволяют получить необходимую уверенность в том, что принятая модель данных является вполне приемлемой. По завершении этапа 2 каждая локальная логическая модель данных при необходимости может применяться для подготовки прототипов реализаций базы данных, предназначенных для отдельных типов пользователей приложения. [6, С.110]
     На  третьем этапе выполняется объединение  локальных логических моделей данных (отражающих представление о предметной области отдельных типов пользователей) в единую глобальную логическую модель данных всего предприятия (обобщающую представления о предметной области всех типов пользователей). Глобальная логическая модель проверяется по такому же принципу, как и локальные модели; это позволяет убедиться в том, что ее структура является правильной и поддерживает все необходимые транзакции. Этот этап обычно требуется, если приложение состоит более чем из одного представления. [6, С.200]
     В предлагаемой методологии проектирования существенная роль отводится конечным пользователям, которые постоянно привлекаются разработчиками для ознакомления и проверки создаваемых моделей данных и сопроводительной документации. Проектирование баз данных обычно представляет собой циклический процесс, имеющий конкретную точку начала, практически не имеющий конца и включающий неограниченное число циклов улучшений и доработок.
     Этот  процесс выглядит как четко определенная последовательность процедур, это ни в коей мере не означает, что разработка базы данных непременно должна выполняться именно таким образом. Весьма вероятно, что сведения, полученные при выполнении некоторого этапа, могут потребовать изменить решения, принятые на одном из предыдущих этапов. Практика предварительного анализа возможных результатов выполнения последующих этапов может оказаться полезной при выполнении начальных этапов разработки. Предлагаемую методологию следует рассматривать как общую схему, которая позволит повысить эффективность работы по проектированию баз данных. [6, С.210]

     2.1 Концептуальное, логическое и физическое проектирование базы данных

 
     В предлагаемой методологии весь процесс проектирования базы данных подразделяется на три основных этапа: концептуальное, логическое и физическое проектирование.
     Концептуальное  проектирование базы данных. Конструирование информационной модели предприятия, не зависящей от каких-либо физических условий реализации.
     Концептуальное  проектирование базы данных начинается с создания концептуальной модели данных предприятия, полностью независимой от любых деталей реализации. К последним относятся выбранный тип СУБД, состав программ приложения, используемый язык программирования, конкретная аппаратная платформа, вопросы производительности и любые другие физические особенности реализации. [7, С.60]
     Логическое  проектирование базы данных. Конструирование информационной модели предприятия на основе существующих конкретных моделей данных, но без учета используемой СУБД и прочих физических условий реализации.
     Логическое  проектирование базы данных заключается в преобразовании концептуальной модели данных в логическую модель данных предприятия с учетом выбранного типа СУБД (например, предполагается использование некоторой реляционной СУБД). Логическая модель данных является источником информации для этапа физического проектирования. Она предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет исключительно важное значение для выбора действительно эффективного проектного решения. [7, С.90]
     Физическое проектирование базы данных. Описание конкретной реализации базы данных, размещаемой во внешней памяти. Физический проект описывает базовые отношения, определяет организацию файлов и состав индексов, применяемых для обеспечения эффективного доступа к данным, а также регламентирует все соответствующие ограничения целостности и меры защиты.
     Физическое  проектирование базы данных предусматривает  принятие разработчиком окончательного решения о способах реализации создаваемой  базы. Поэтому физическое проектирование обязательно производится с учетом всех особенностей используемой СУБД. Между этапами физического и логического проектирования всегда имеется определенная обратная связь, поскольку решения, принятые на этапе физического проектирования с целью повышения производительности разрабатываемой системы, могут потребовать определенной корректировки логической модели данных. [7, С.189]

     2.2  Методология физического проектирования базы данных

 
     Создание  локальной физической модели данных предприятия на основе представления о предметной области каждого отдельного типа пользователей.
     На  первом этапе проектирования базы данных должна быть разработана концептуальная модель данных для каждого представления, охватывающего предметную область данного предприятия; такая модель данных называется локальной концептуальной моделью данных для рассматриваемого представления. В процессе анализа необходимо выявить все пользовательские представления, которые требуются для разрабатываемого приложения, и предусмотреть возможность объединения некоторых представлений для создания обобщенного представления, обозначенного соответствующим идентификатором, в зависимости от степени перекрытия отдельных представлений. На этапе сбора требований к данным и их анализа определено, что для приложения DreamHome требуются следующие представления.
    Представление Branch, состоящее из пользовательских представлений таких типов пользователей, как Director и Manager.
    Представление Staff, состоящее из пользовательских представлений таких типов пользователей, как Supervisor и Assistant.
     В настоящей главе приведен пример создания локальной концептуальной модели данных для представления Staff учебного проекта DreamHome, а в следующей главе показано, как преобразовать локальную концептуальную модель данных в локальную логическую модель данных для этого представления, а затем описано, каким образом можно выполнить слияние полученной локальной логической модели с локальной логической моделью для представления Branch. Каждая локальная концептуальная модель данных состоит из следующих компонентов:
    типы сущностей;
    типы связей;
    атрибуты и домены атрибутов;
    первичные ключи;
    альтернативные ключи;
    ограничения целостности;
     Физическая модель данных дополняется документацией, создаваемой в процессе разработки этой модели, включая словарь данных. Подробные сведения о сопроводительной документации, которая может быть подготовлена на различных этапах, приведены при описании этих этапов. На первом этапе разработки должно быть выполнено следующее.
    Определение типов сущностей.
    Определение типов связей.
    Определение атрибутов и связывание их с типами сущностей и связей.
    Определение доменов атрибутов.
    Определение атрибутов, являющихся потенциальными и первичными ключами.
    Обоснование необходимости использования понятий расширенного моделирования (необязательный этап).
    Проверка модели на отсутствие избыточности,
    Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.
    Обсуждение локальных концептуальных моделей данных с конечными пользователями. [8, С.178]
     Первый  этап создания локальной концептуальной модели данных состоит в определении основных объектов, которые могут интересовать пользователя. Эти объекты являются типами сущностей, входящих в модель (см. раздел 11.1). Один из методов идентификации сущностей состоит в изучении спецификаций по выполнению конкретных функций пользователя на данном предприятии. Из этих спецификаций следует извлечь все используемые в них существительные или сочетания существительного и прилагательного (например, "табельный номер", "фамилия работника", "номер объекта недвижимости", "адрес объекта недвижимости", "арендная плата", "количество комнат"). Затем среди них выбираются самые значимые объекты (категории работников, направления деятельности) или важные концепции и исключаются все существительные, которые просто определяют другие объекты. Например, такие свойства, как "табельный номер" и "фамилия работника", могут быть объединены в сводном объекте под названием "работник" (staff), тогда как свойства "номер объекта недвижимости", "адрес объекта недвижимости", "арендная плата" и "количество комнат" можно объединить в сущности под названием "объект недвижимости" (PropertyForRent). [9, С.112]
     Альтернативный  способ идентификации сущностей  состоит в поиске объектов, которые существуют независимо от других. Например, объект Staff, безусловно, является сущностью, поскольку очевидно, что компания не может не иметь работников, хотя на каком-то этапе проектирования могут не рассматриваться такие атрибуты сущности "работник", как имя, должность и дата рождения. В этой работе существенную помощь могут оказать пользователи создаваемого приложения. 
 
 
 
 
 

     Заключение

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


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.