Базы данных

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

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

     Первый  вариант состоит в том, чтобы ограничиться использованием обычных типов данных и не использовать null-значения, а вместо неизвестных данных вводить либо нулевые значения, либо значения специального вида - например, договориться, что строка "АДРЕС НЕИЗВЕСТЕН" и есть те данные, которые нужно вводить вместо неизвестного адреса. В любом случае на пользователя (или на разработчика) ложится ответственность на правильную трактовку таких данных. В частности, может потребоваться написание специального программного кода, который в нужных случаях "вылавливал" бы такие данные. Проблемы, возникающие при этом очевидны - не все данные становятся равноправны, требуется дополнительный программный код, "отслеживающий" эту неравноправность, в результате чего усложняется разработка и сопровождение приложений.

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

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

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

     Подмножество атрибутов  отношения называется внешним ключом, если:

1. Существует отношение  с потенциальным ключом;
2. Каждое значение  в отношении  всегда совпадает со значением  для некоторого кортежа либо является null-значением.

Замечание 1. Внешний ключ, также как и  потенциальный, может быть простым и составным.

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

Замечание 3. Внешний ключ, как правило, не обладает свойством уникальности. Так и должно быть, т.к. в дочернем отношении может быть несколько кортежей, ссылающихся на один и тот же кортеж родительского отношения. Это, собственно, и дает тип отношения "один-ко-многим".

Замечание 4. Если внешний ключ все-таки обладает свойством уникальности, то связь между отношениями имеет тип "один-к-одному". Чаще всего такие отношения объединяются в одно отношение, хотя это и не обязательно.

Замечание 5. Хотя каждое значение внешнего ключа  обязано совпадать со значениями потенциального ключа в некотором  кортеже родительского отношения, то обратное, вообще говоря, неверно. Например, могут существовать поставщики, не поставляющие никаких товаров.  

Замечание 6. Для внешнего ключа не требуется, чтобы он был компонентом некоторого потенциального ключа 

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

     Т.к. внешние ключи фактически служат ссылками на кортежи в другом (или в том же самом) отношении, то эти ссылки не должны указывать на несуществующие объекты.

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

     В Access многие ограничения целостности  могут задаваться самим пользователем при создании таблицы.

     Тип поля. Он определяет допустимые символы, которые могут быть использованы при его заполнении (в частности, не допускается ввод текста в числовые поля).

     Для некоторых типов полей, например, поля типа «дата», осуществляется и более сложная проверка. Если допущена ошибка в типе данных или неправильно введена дата, то пользователь должен обязательно исправить ошибку, так как СУБД не дает других возможностей продолжить работу.

     Ряд свойств полей также позволяет  обеспечивать контроль целостности:

1. размер поля;
2. формат поля;
3. маска ввода;
4. значение по умолчанию;
5. условия на значения;
6. сообщение об ошибке;
7. обязательное поле;
8. пустые строки;
9. индексированное поле.

     Каждое  из них в той или иной степени  связано с ограничениями целостности.

     Существует 3 подхода, поддерживающих целостность:

1. Вообще запрещается производить удаление кортежа, для которого существуют ссылки;
2. При удалении кортежа, на который существуют ссылки, во всех ссылающихся кортежах значения внешнего ключа автоматически становятся полностью неопределенными;
3. При удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи - каскадное удаление.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

6. Организация ввода данных в БД

      Для проектировщика БД удобнее вводить и редактировать  данные в режиме «Таблица». Поэтому  я создала несколько таблиц, соответствующих  сущностям БД. 
 
 
 
 
 
 
 
 

Рисунок 3. - Таблица «Товары» 

Рисунок 4. - Таблица «Клиенты» 
 

 
 
 
 
 
 
 
 
 
 

Рисунок 5. – Таблица «Поставщики»

 
 
 
 
 
 
 
 
 
 
 
 

Рисунок 6. - Таблица «Поставки» 

 
 
 
 
 
 
 
 
 
 
 
 

Рисунок 7. – Таблица «Продажи» 

 
 
 
 
 
 
 
 
 

Рисунок 8. – Таблица «Менеджеры поставок» 
 
 
 

 
 
 
 
 

Рисунок 9. – Таблица «Менеджеры поставок» 

     На  основе этих таблиц и занесенных в  них данных созданы формы. Они предназначены для наглядности информации, хранящейся в БД.  Представим основные формы - «Поставка товара» и «Продажа товара».

       
 
 
 
 
 
 
 

     Рисунок 10. – Форма «Поставки»

       
 
 
 
 
 
 
 

Рисунок 11. – Форма «Продажа» 

     Как видно на Рисунках 10 и 11, я использовала подчиненную форму.

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

7. Получение отчетов

     Часто при работе с базами данных появляется необходимость создания документов для подведения каких-либо итогов, и, которые, как правило, выводятся на печать. К таким документам в Access относятся отчеты.

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

     Для моей БД я создала следующие отчеты:

1. Продажа товара (сортировка по коду клиента);
2. Продажа товара;
3. Поставка товара (сортировка по месяцам);
4. Поставка товара.

  
 
 
 
 
 
 
 
 
 

     Рисунок 12. – Отчет о продаже товаров (по коду клиента)

       
 
 
 
 
 
 
 
 

      Рисунок 13. – Отчет о продаже 
 

 
 
 
 
 
 
 
 
 
 
 
 
 

Рисунок 4. – Отчет о поставках по месяцам 

 
 
 
 
 
 
 
 
 
 
 
 
 

Рисунок 15. – Отчет о поставках

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

8. Разработка интерфейса

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

1. задачи, которые в базе данных выполняются «вручную», в приложении максимально автоматизированы;
2. для приложения разрабатывается специальный интерфейс, позволяющий сделать обслуживание базы данных максимально удобным для пользователя.

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

1. ассортимент товаров должен изменяться;
2. каждый менеджер вводит данные о поставке и продаже товаров;
3. список сотрудников может меняться;
4. периодически требуется выводить отчеты о поставках и продажах товаров.

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

 
 
 
 
 
 
 
 
 
 

Рисунок 16. – Главная кнопочная форма