Курсовое_проектир методич указания. Методические указания к курсовому проектированию по курсу "Базы данных" Составитель
 Скачать 340.75 Kb.
|
|
ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ Методические указания к курсовому проектированию по курсу "Базы данных" Составитель к.т.н., доцент И.П. Карпова УДК 681.3 Проектирование реляционных баз данных: Метод. указания к курсовому проектированию по курсу "Базы данных" / Московский государственный ин- ститут электроники и математики; Сост.: И.П. Карпова. – М., 2010 – 32 с. Курсовое проектирование посвящено изучению методов проектирования реляционных баз данных, особое внимание уделено этапам инфологического и логического проектирования. . СОДЕРЖАНИЕ ЦЕЛИ РАБОТЫ Цель курсового проектирования – применение на практике знаний, полученных в процессе изучения курса "Базы данных" [1], и получение практических навыков создания автоматизированных информационных систем (АИС), основанных на базах данных. 1. ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ 1.1. Общие положения Проектирование базы данных (БД) является одной из наиболее сложных и ответственных задач, связанных с созданием АИС. Проектирование базы данных – это процесс, который подразумевает использование определённой технологии. Никто не сомневается в том, что в случае нарушения технологии изготовления печатной платы, например, эта плата либо вообще не будет работать, либо не будет соответствовать заявленным характеристикам. Но почему-то считается, что соблюдать технологию проектирования БД (и вообще программного обеспечения) совершенно необязательно. И начинают работу по реализации реляционной БД с создания таблиц. Получившаяся в ходе такого "проектирования" база данных будет ненадёжной, неэффективной и сложной в сопровождении. (Исключением могут быть случаи простых предметных областей, которые можно отразить в базе данных, состоящей из 3-4 таблиц). Поэтому при создании базы данных необходимо придерживаться определённой технологии проектирования БД. Опишем вкратце процесс проектирования реляционной базы данных. (Более подробно этот процесс изложен в [1, 2]). База данных – это, фактически, модель предметной области (ПрО). Значит, для создания БД надо сначала проанализировать ПрО и создать её модель (это называется инфологическим проектированием). Основой для анализа предметной области служат документы, которые отражают ПрО, и информация, которую можно получить от специалистов этой предметной области в процессе общения с ними. Для анализа берутся те документы, которые имеют отношение к решаемой задаче. Изучение документов позволяет выявить объекты (сущности ПрО) и атрибуты сущностей – данные, которые должны храниться в БД. Из общения со специалистами необходимо извлечь сведения об особенностях ПрО, которые позволяют установить ограничения целостности, зависимости и связи между объектами (субъектами) предметной области. Также специалисты обладают знаниями о том, каковы алгоритмы обработки данных и какие задачи ставятся перед информационной системой. Модель ПрО может быть описана любым удобным для разработчика способом (словесное описание, набор формул, диаграмма потоков данных и т.п.). Но, если при проектировании баз данных используется метод сущность–связь, то схема ПрО выполняется в виде ER–диаграммы (entity-relation diagram, диаграмма «сущность-связь»). После создания модели ПрО определяются требования к операционной обстановке: какое аппаратное и программное обеспечение необходимо для реализации БД и АИС в целом. Основные технические параметры (объём оперативной и дисковой памяти, наличие сетевой платы и др.) определяются исходя из планируемого объёма БД, режима работы (локальный или удалённый доступ) и требований к эффективности работы системы (например, ко времени реакции на запрос пользователя или к общей производительности БД). В зависимости от планируемой нагрузки (интенсивности запросов) и требований к надёжности выбирается операционная система. Затем осуществляется выбор СУБД, под управлением которой будет работать создаваемая база данных. На следующем этапе – этапе логического проектирования – ER-диаграмма формальным способом преобразуется в схему реляционной базы данных (РБД). На основании схемы РБД и описания сущностей ПрО составляются отношения (таблицы) базы данных. Потом выполняется нормализация отношений. Это необходимо сделать для того, чтобы исключить нарушения логической целостности данных и повысить таким образом надёжность и достоверность данных. В отдельных случаях после нормализации может выполняться денормализация, но причина для этого может быть только одна: повышение эффективности выполнения критических запросов. В результате всех этих операций создаётся концептуальная схема БД – основной документ для базы данных. Далее, на этапе физического проектирования полученные отношения описываются на языке DDL (Data definition language) – языке определения данных, который поддерживается выбранной СУБД. Также необходимо определить способы хранения данных (кластеризация, хеширование) и способы доступа к данным (индексирование) и создать соответствующие индексы и кластеры (если нужно). Если пользователей АИС можно разделить на группы по характеру решаемых задач, то для каждой группы создаётся свой набор прав доступа к объектам БД. 1.2. Последовательность проектирования базы данных Итак, процесс проектирования включает в себя следующие шаги: Определение задач, стоящих перед базой данных. Сбор и анализ документов, относящихся к исследуемой предметной области. Описание особенностей ПрО, которые позволяют установить зависимости и связи между объектами (субъектами) предметной области. Создание модели предметной области. Определение групп пользователей и перечня задач, стоящих перед каждой группой. Выбор аппаратной и программной платформы для реализации БД. Выбор СУБД (системы управления базой данных). Создание логической схемы БД. Создание схем отношений, определение типов данных атрибутов и ограничений целостности. Нормализация отношений (до третьей или четвёртой нормальной формы). Определение прав доступа пользователей к объектам БД. Написание текста создания основных объектов базы данных на языке SQL в синтаксисе выбранной СУБД (пользователи, таблицы и др.). Написание текста создания вспомогательных объектов базы данных (представления, индексы, триггеры, роли и т.д.). Эти шаги можно объединить с 5 этапов: Инфологическое проектирование (1-5). Определение требований к операционной обстановке, в которой будет функционировать информационная система (6). Выбор системы управления базой данных (СУБД) и других инструментальных программных средств (7). Логическое проектирование БД (8-11). Физическое проектирование БД (12-13). На сегодняшний день не существует формальных способов моделирования реальности, но инфологический подход закладывает основы методологии проектирования базы данных как модели предметной области. 1.2.1. Инфологическое проектирование Основными задачами этапа инфологического проектирования являются определение предметной области системы и формирование взгляда на неё с позиций сообщества будущих пользователей БД, т.е. информационно-логической модели ПрО. Инфологическая модель ПрО представляет собой описание структуры и динамики ПрО, характера информационных потребностей пользователей в терминах, понятных пользователю и не зависимых от реализации БД. Это описание выражается в терминах не отдельных объектов ПрО и связей между ними, а их типов, связанных с ними ограничений целостности и тех процессов, которые приводят к переходу ПрО из одного состояния в другое. Основными подходами к созданию инфологической модели предметной области являются [1]: Функциональный подход к проектированию БД ("от задач"). Предметный подход к проектированию БД ("от предметной области"). Метод "сущность-связь" (entity–relation, ER–method). Мы будем использовать метод "сущность–связь" как наиболее распространённый. Приведём основные термины, которыми мы будем пользоваться: Сущность – это объект, о котором в системе будут накапливаться данные. Для сущности указывается название и тип (сильная или слабая). Сильные сущности существуют сами по себе, а существование слабых сущностей зависит от существования сильных. Атрибут – свойство сущности. Различают: Идентифицирующие и описательные атрибуты. Идентифицирующие позволяют отличить один экземпляр сущности от другого. Описательные атрибуты заключают в себе интересующие нас свойства сущности. Составные и простые атрибуты. Простой атрибут имеет неделимое значение. Составной атрибут является комбинацией нескольких элементов, возможно, принадлежащих разным типам данных (ФИО, адрес и др.). Однозначные и многозначные атрибуты (могут иметь соответственно одно или много значений для каждого экземпляра сущности). Например, дата рождения – это однозначный атрибут, а номер телефона – многозначный. Основные и производные атрибуты. Значение основного атрибута не зависит от других атрибутов; значение производного атрибута вычисляется на основе значений других атрибутов. Например, возраст вычисляется на основе даты рождения и текущей даты. Обязательные и необязательные (первые должны быть указаны при размещении данных в БД, вторые могут не указываться). Для каждого атрибута необходимо определить название, указать тип данных и описать ограничения целостности – множество значений, которые может принимать данный атрибут. Связь – это осмысленная ассоциация между сущностями. Для связи указывается название, тип (факультативная или обязательная), степень (1:1, 1:n или m:n) и кардинальность (унарная, бинарная, тернарная или n-арная). На рис. 1 приведены обозначения, которые мы будем использовать в ER-диаграммах.  Рис.1. Обозначения, используемые в ER-диаграммах 1.2.2. Определение требований к операционной обстановке На этом этапе производится оценка требований к вычислительным ресурсам, необходимым для функционирования системы, определение типа и конфигурации конкретной ЭВМ, выбор типа и версии операционной системы. Объём вычислительных ресурсов зависит от предполагаемого объёма проектируемой базы данных и от интенсивности их использования. Если БД будет работать в многопользовательском режиме, то требуется подключение её к сети и наличие соответствующей многозадачной операционной системы [1]. 1.2.3. Выбор СУБД и других программных средств Выбор СУБД осуществляется на основании таких критериев, как тип модели данных и её адекватность потребностям рассматриваемой ПрО; характеристики производительности; набор функциональных возможностей; удобство и надежность СУБД в эксплуатации; стоимость СУБД и дополнительного программного обеспечения [1]. 1.2.4. Логическое проектирование реляционной БД На этапе логического проектирования разрабатывается логическая (концептуальная) структура БД. Для реляционной модели существуют формальные правила, которые позволяют преобразовать инфологическую модель ПрО в виде ER-диаграммы в логическую схему базы данных. Кроме получения схемы БД в целом на этом этапе выполняют создание схем отношений и их нормализацию. Этот этап более подробно рассмотрен в п.2 "Пример проектирования реляционной базы данных". 1.2.5. Физическое проектирование БД Этап физического проектирования заключается в определении схемы хранения, т.е. физической структуры БД. Схема хранения зависит от той физической структуры, которую поддерживает выбранная СУБД. Физическая структура БД, с одной стороны, должна адекватно отражать логическую структуру БД, а с другой стороны, должна обеспечивать эффективное размещение данных и быстрый доступ к ним. Результаты этого этапа документируются в форме схемы хранения на языке определения данных (DDL, Data Definition Language) выбранной СУБД. Принятые на этом этапе решения оказывают огромное влияние на производительность системы. Одной из важнейших составляющих проекта базы данных является разработка средств защиты БД. Защита данных имеет два аспекта: защита от сбоев и защита от несанкционированного доступа. Для защиты от сбоев на этапе физического проектирования разрабатывается стратегия резервного копирования. Для защиты от несанкционированного доступа каждому пользователю доступ к данным предоставляется только в соответствии с его правами доступа, набор которых также является составной частью проекта БД. |