Вторая  нормальная форма (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. Проектирование базы  данных

 

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

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