Министерство  образования и науки Российской Федерации 

Государственное образовательное учреждение высшего 

профессионального образования

«РЯЗАНСКИЙ  ГОСУДАТСТВЕННЫЙ РАДИОТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» 

Кафедра ЭВМ 
 
 
 

                                                                                                    К защите            

                                                                                                     Руководитель проекта

                                                                                                                      _____________________________

                                                                                                                                                дата, подпись 
 
 

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

К КУРСОВОМУ ПРОЕКТУ

по дисциплине

«Системы управления базами данных» 
 
 
 
 
 
 
 
 

Рязань 2009

Оглавление

1. Теоретическая часть

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

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

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

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

       При проектировании базы данных решаются две  основные проблемы:

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

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

       Проблема  проектирования реляционной базы данных состоит в обоснованном принятии решений о том, из каких отношений (таблиц) должна состоять БД и какие атрибуты (характеристики и свойства) должны быть у этих отношений.

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

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

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

       Эта структура должна удовлетворять  представления пользователя данными.

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

       В настоящее время существует два различных подхода к моделированию данных:

1. модель базы данных типа «сущность - связь» (entity-relationship model), имеющая значительное количество сторонников среди профессионалов;
2. семантическая объектная модель (некоторые считают ее более простой и точной).

       При проектировании базы данных используем первый, наиболее распространенный метод моделирования данных – «сущность - связь».

       Эта модель введена Питером Ченом в 1976 году.

       Этот  выбор объясняется в первую очередь  наглядностью представления отношений  между объектами и поведения  элементов базы данных. На этом подходе к моделированию данных основываются большинство средств автоматизации проектирования (CASE), применение которых значительно сокращает время разработки, а так же предотвращают возникновение многих ошибок.

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

       Инфологическая  модель является проблемно-ориентированной  и системно-независимой, т.е. не зависимой от конкретной СУБД, операционной системы и аппаратного обеспечения ЭВМ.

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

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

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

       Центральной компонентой инфологической модели является описание объектов предметной области и связей между ними (ER-модель).

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

       Основными конструктивными элементами инфологических моделей являются сущности, связи  между ними, идентификаторы (ключи) и свойства (атрибуты).

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

       Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.

       Атрибут – поименованная характеристика сущности.

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

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

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

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

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

       Одно  из требований — реляционная база данных должна быть нормализована. Процесс нормализации имеет своей целью устранение избыточности данных и заключается в приведении к третьей нормальной форме (или к нормальной форме Бойса-Кодда).

       Нормализацией называется формальная процедура, в ходе которой атрибуты данных группируются в таблицы, а таблицы группируются в базу данных (БД).

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

       В терминах БД столбцы таблицы называются полями, а ее строки - записями.

       Нормализация  выполняется поэтапно. Первые три  шага были описаны доктором Э.Ф. Коддом в статье "Дальнейшая нормализация реляционной модели базы данных" в 1972г.

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

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

       Вторая  нормальная форма (2НФ). Для 2НФ требуется, чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен.

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

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

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

       Для третьей нормальной формы (ЗНФ) требуется, чтобы все не ключевые столбцы таблицы зависели от первичного ключа таблицы, но были независимы друг от друга. Для этого требуется, чтобы таблицы были приведены к 1НФ и 2НФ.

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

       Если  в отношении имеется много  функциональных зависимостей, 4НФ не устраняет избыточность, то применяют пятую нормальную форму (ЗНФ).

       Разложение  отношений из 4НФ в пятую нормальную форму должно быть выполнено так, чтобы каждая проекция, полученная из 4НФ, содержала не менее одного возможного ключа и хотя бы один неключевой атрибут из исходного отношения. Для 5НФ требуется, чтобы можно было восстановить исходную таблицу на основе информации таблиц, на которые она была разбита. Кроме того, необходимо, чтобы таблицы соответствовали ЗНФ, а при наличии отношений "многие-ко-многим" - 4НФ.

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

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

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

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

• Таблицы
• Правила
• Умолчания
• Определяемые пользователем типы данные
• Представления
• Хранимые процедуры
• Триггеры

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

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

      Базовый синтаксис оператора создания таблицы  имеет следующий вид:

        CREATE TABLE имя_таблицы

        (имя_столбца тип_данных [,...n]) 

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

        CREATE RULE <имя правила> AS

        <условия  правила> 

     Привязка  правил осуществляется с помощью  процедуры sp_bindrule: 

sp_bindrule имя_правила, таблица.столбец  

     Умолчания (значения по умолчанию) – это значения, которые заносятся в определенную колонку, когда не указано явно никакого значения. Оператор CREATE DEFAULT имеет следующий синтаксис: 

     CREATE DEFAULT имя_умолчания AS выражение-константа

     Процедура sp_bindefault имеет следующий синтаксис: 

     sp_bindefault имя_умолчания, таблица.столбец | определенный_пользователем_тип_данных 

     Привязка  умолчаний осуществляется так:

     sp_bindefault 'Имя умолчания', 'таблица.столбец'  

     Пользовательские  типы данных – это типы данных, которые создает пользователь на основе системных типов данных, когда в нескольких таблицах необходимо хранить однотипные значения; причем нужно гарантировать, что столбцы в таблице будут иметь одинаковый размер, тип данных и чувствительность к значениям NULL. Синтаксис: 

     sp_addtype имя пользовательского типа, системный тип данных, 'NOT NULL'|'NULL'  

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

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

     Создания  и изменения представлений в  стандарте языка и реализации в MS SQL Server совпадают и представлены следующей командой: 

         { CREATE| ALTER} VIEW имя_просмотра

         [(имя_столбца [,...n])]

         [WITH ENCRYPTION]

         AS SELECT_оператор

         [WITH CHECK OPTION] 

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

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

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

     {CREATE | ALTER } PROC[EDURE] имя_процедуры

         [{@имя_параметра тип_данных} [Значение по умлочанию][OUTPUT] ][,...n]

     [WITH {RECOMPILE, ENCRYPTION }]

     AS

        sql_оператор [...n]

     GO

     Триггеры  являются одной из разновидностей хранимых процедур. Их исполнение происходит при выполнении для таблицы какого-либо оператора языка манипулирования данными (DML). Триггеры используются для проверки целостности данных, а также для отката транзакций.

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

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

Основной формат команды CREATE TRIGGER показан ниже:

       CREATE TRIGGER имя_триггера

       ON <имя_таблицы>|<представление>

       [WITH ENCRYPTION]

     {AFTER|INSTEAD OF TRIGGER}{INSERT,UPDATE,DELETE}

     AS

      <тело_триггера>

       GO

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

Описание  предметной области 

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