Проектирование и создание реляционной базы данных

 
 
 
 
 
 

     ВВЕДЕНИЕ 

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

"Базой  данных" часто упрощённо или  ошибочно называют системы управления  базами данных (СУБД) - системное  программное обеспечение, предназначенное  для организации ведения БД.

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

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

     В данной курсовой работе ставится задача – разработать базу данных «Ювелирный магазин». Для этого необходимо рассмотреть формирование исходного отношения, установить зависимости между атрибутами, перейти ко второй нормальной форме (НФ2), затем к третей нормальной форме (НФ3) и, наконец, к третей усиленной форме Бойса-Кодда (НФБК), создать структуру таблиц, схему данных. Далее необходимо создать формы, запросы и отчеты. 
 

         
 
 

 1 ПРОЕКТИРОВАНИЕ БД МЕТОДОМ НОРМАЛЬНЫХ ФОРМ 

     Реляционная база данных – база данных, основанная на реляционной модели данных.

     Понятие «реляционный» (англ. relation — отношение) появилось в 1970 году и связано с разработками известного английского специалиста из компании IBM в области систем баз данных Эдгара Кодда.

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

     Для работы с реляционными базами данных применяют реляционные СУБД, наиболее распространенные из которых – это MS Access и Visual FoxPro.

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

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

- каждый элемент таблицы — один элемент данных;

      - все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.);

     - каждый столбец имеет уникальное имя;

     - одинаковые строки в таблице отсутствуют;

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

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

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

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

     Существуют  следующие виды нормальных форм: 1НФ, 2НФ, 3НФ, нормальная форма Бойса–Кодда, 4НФ, 5НФ, доменно-ключевая нормальная форма и 6НФ.

     При решении практических задач в  большинстве случаев третья нормальная форма является достаточной. Процесс  проектирования реляционной базы данных, как правило, заканчивается приведением к 3НФ.

     Процесс проектирования базы данных методом  нормальных форм (нормализацией) является итерационным, заключающемся в последовательном переводе отношений из первой нормальной формы к нормальным формам более  высокого порядка по определенным правилам. Каждая последующая нормальная форма ограничивает определенный тип функциональной зависимости, устраняет аномалии, сохраняя при этом свойства предшествующих форм [1, 3 - 5].

     Рассмотрим  исходное отношение «Украшения» (приложение А) базы данных «Ювелирный магазин». Перечислим имена атрибутов и их краткие характеристики:

     Артикул – регистрационный номер каждого изделия;

     Марка – наименование производителя данного изделия;

     Класс – ценовая категория, к которой относится изделие;

     Вид – вид изделия;

     Название  – название изделия;

     Страна – страна-производитель изделия;

     Покупатель – ФИО покупателя изделия;

     Форма оплаты – форма произведения оплаты за изделие;

     Продавец – ФИО продавца магазина;

     Номер чека – номер чека на приобретенное изделие;

          Рассматриваемое исходное отношение  содержит избыточность данных, от которой необходимо освободиться с помощью нормализации. Процесс нормализации основывается на формуле: ИО – ЧЗ = 2НФ – ТЗ = 3НФ.

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

          На первом этапе отношения «Украшения» определяем составной ключ (Артикул, номер чека) и все функциональные зависимости:

     1) Артикул, номер чека – продавец. Зная артикул изделия и номер чека на приобретенное изделие, мы сможем однозначно определить ФИО продавца (ПЗ).

     2) Артикул – марка. Артикул для каждого изделия уникален, с ним связана только одна марка, но могут продаваться другие изделия той же марки (ЧЗ).

     3) Номер чека – покупатель. Номер чека уникален, с ним связан только один покупатель изделия, но покупатель может приобрести несколько изделий по разным чекам (ЧЗ).

     4) Номер чека – форма оплаты. Номер чека уникален, его можно оплатить только одним способом оплаты, но этим же способом оплаты можно оплатить другие чеки (ЧЗ).

     5) Артикул – вид. Артикул уникален, с ним связан только одно изделие определенного вида, но могут быть и другие изделия такого же вида (ЧЗ).

     6) Артикул – название. Артикул уникален, с ним связано только одно изделие, имеющие определенное название, но могут быть и другие изделия с таким же названием (ЧЗ).

     7) Название – класс. Название уникально. Каждое изделие имеет свое название, и названию соответствует определенный класс, но могут быть и другие изделия того же класса  (ТЗ).

     8) Название – страна. Название уникально. Каждое изделие произведено в определенной стране, но есть и другие изделия, произведенные в этой же стране (ТЗ).

     Зависимости между атрибутами можно представить  в виде схемы (рисунок 1):

     

     Рисунок 1 – Схема зависимостей между  атрибутами 

     Исходное  отношение «Украшения» находится в 1НФ, поскольку все его атрибуты простые. Для совершенствования базы данных необходимо перейти во 2НФ.

     Таблица находится во второй нормальной форме, если она находится в первой нормальной форме, и при этом любой её атрибут, не входящий в состав первичного ключа, функционально полно зависит  от первичного ключа. Функционально  полная зависимость означает, что  атрибут функционально зависит  от всего первичного составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов (частей). Или другими словами: в 2НФ нет неключевых атрибутов, зависящих от части составного ключа     (+ выполняются условия 1НФ).

     Для перехода во 2НФ, отделяем частичные  зависимости, разбивая исходное отношение на 3 отдельные таблицы:

     1) Продажи (Артикул, Номер чека, Продавец) – содержит составной ключ.

     2) Изделия (Артикул, Название, Вид, Класс, Страна, Марка).

     3) Чеки (Номер чека, Форма оплаты, Покупатель).

     На  данном этапе устранить избыточность по-прежнему не удалось. Совершаем переход  в ЗНФ. Таблица находится в третьей нормальной форме (3НФ), если она находится в 2НФ и при этом любой ее неключевой атрибут зависит только от первичного ключа. Таким образом, отношение находится в 3НФ тогда и только тогда, когда оно находится во 2НФ и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых. Транзитивной зависимостью неключевых атрибутов от ключевых называется следующая: A → B и B → C, где A – набор ключевых атрибутов (ключ), B и С – различные множества неключевых атрибутов.

     Т.е. на данном этапе удаляем транзитивные зависимости, создаем дополнительные таблицы справочники и для  осуществления связей между таблицами и для удобства работы в СУБД вводим атрибуты-идентификаторы: Марка – код марки, страна – код страны, название – код названия, класс – код класса.

     Получаем  следующие таблицы:

     1) Чеки (Номер чека, Форма оплаты, Покупатель)

     2) Продажи (Артикул, Номер чека, Продавец) – содержит составной ключ

     3) Страны (Код страны, Страна)

     4) Классы (Код класса, Класс)

     5) Марки (Код марки, Марка, Код класса, Код страны)

     6) Изделия (Артикул, Код марки, Вид, Название)

     7) Типы (Код названия, Название).

     Все полученные отношения находятся  в 3НФ.

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

     Нормальная  форма Бойса–Кодда (НФБК) - это модификация третьей нормальной формы. Таблица находится в НФБК, если она находится в 3НФ, и при этом отсутствуют функциональные зависимости атрибутов первичного ключа от неключевых атрибутов. Любая сущность с единственным возможным ключом, соответствующая требованиям третьей нормальной формы, автоматически находится в НФБК.

     В нашем случае подобных зависимостей нет. Результатом проектирования является база данных «Ювелирный магазин», состоящая из следующих таблиц: Чеки, Продажи, Страны, Классы, Марки, Изделия, Типы (приложение Б). В полученной базе данных имеет место необходимое дублирование данных, но отсутствует избыточное. Процесс проектирования базы данных «Ювелирный магазин» на этом можно считать завершенным.

       
 
 
 

      
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

  
 

2 СОЗДАНИЕ  БД В MS ACCESS 

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