Основой для учета, контроля и планирования служат всевозможные картотеки, регистрационные журналы, списки и т.д. Они постепенно накапливаются и обновляются. При большом объеме информации поиск и обобщение необходимых сведений, осуществляемых вручную, представляют собой довольно трудоемкий процесс. Поэтому и возникла необходимость создания баз данных.
В настоящее время, несмотря на повышение компьютеризации общества, до сих пор нет средств, позволяющих в достаточной мере автоматизировать процесс ведения документации и отчетности.
Одной из составных задач можно рассматривать проблему ведения учета строительных материалов на складе.
Обширные объёмы информационных потоков, обрабатываемых в любой организации, направлены в основном на создание управленческих документов. А управленческие документы, в свою очередь, на принятие управленческих решений, то есть основной функции любой организации.
Внедрение автоматизированных информационных систем в деятельность различных организаций создает возможности для повышения качества документационного обеспечения управления и позволяет повысить производительность и качество управленческого труда. Они позволяют структурировать, хранить и извлекать информацию оптимальным для пользователя способом.
База данных (БД) — это компьютеризованная система, предназначенная для хранения информации и предоставления ее по требованию.
Задача базы данных состоит в хранении всех представляющих интерес данных в одном или нескольких местах, причем таким способом, который заведомо исключает ненужную избыточность.
Создание баз данных преследует две основные цели: понизить избыточность данных и повысить их надежность. Между физической базой данных и пользователями системы располагается уровень программного обеспечения, именно это и подразумевается под понятием СУБД. Все запросы пользователей на получение доступа к базе данных обрабатываются СУБД. Создание, наполнение, обновление и удаление данных в файлах или таблицах также предоставлены СУБД. Основная задача СУБД — дать пользователю базы данных возможность работать с ней, не вникая во все подробности работы на уровне аппаратного обеспечения.
Целью работы является разработка СУБД «Учет строительных материалов на складе». Для достижения поставленной цели необходимо решить следующие задачи:
- Исследовать предметную область;
- Построить концептуальную модель;
- Осуществить нормализацию таблиц базы данных, приведя к 3-й нормальной форме;
- Разработать базу данных в MS Access;
- Разработать графический интерфейс средствами прикладных программ.
1.Нормализация
Нормализация БД — это формирование модели или процесс проектирования.
Настройка параметров функционирования аппаратного обеспечения
... блок монитор клавиатура 1. Аппаратное обеспечение персональных компьютеров. Системный блок ... корпуса системного блока является параметр, называемый форм-фактором. ... для ввода графических данных устройства выхода данных Принтеры — Лазерные. ... аппаратно. Этот адрес указывает на ПЗУ. В ПЗУ находятся «зашитые» программы, которые записываются туда при создании ... обеспечение. Оно отвечает за взаимодействие с баз
Одни и те же данные могут группироваться в таблицы (отношения) различными способами, т.е. возможна организация различных наборов отношений взаимосвязанных информационных объектов.
Группировка атрибутов в отношениях должна быть рациональной, т.е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления.
Определенный набор отношений обладает лучшими свойствами при включении, модификации, удалении данных, чем все остальные возможные наборы отношений, если он отвечает требованиям нормализации отношений.
Нормализация отношений — формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных.
Выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.
Отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые (далее неделимы).
Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа.
Первая нормальная форма
Отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые (далее неделимы).
Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа.
Первым шагом нормальной формы является сбор всех данных полей:
Название сектора
Код сектора
Заведующий сектором
Номер договора
ФИО
Дата рождения
Адрес
Номер телефона
Должность
Код Материала
Наименование Материала
Количество Материала
Брак
Сектор хранения Материала
Описание Материала
Дата принятия Материала
Код принимаемого Материала
Количество принятого Материала
Сектор куда приняли Материал
Цена закупки Материала
Принимающий Материал
Дата выдачи Материала
Код выданного Материала
Количество выданного Материала
Сектор из которого выдан Материал
Цена продажи Материала
Выдающий Материал
Для этой формы самое главное свойство достаточность, избыток данных в этой форме допускается.
Второй шаг первой нормальной формы:
Определение делимых полей и устранение повторяющихся групп.
Делимые поля — это поля, в которых информация дробная:
Название сектора
Код сектора
Заведующий сектором
Номер договора
Фамилия
Имя
Отчество
Дата рождения
Организация хранения документов в делопроизводстве (на материалах ...
... организации хранения документов в конкретной организации. Объектом дипломной работы является Межрайонная инспекция Федеральной налоговой службы по крупнейшим налогоплательщикам Алтайского края. Предметом соответственно организация хранения его документов в делопроизводстве. Для написания дипломной работы использовались ...
Адрес по прописке
Номер телефона
Должность
Код Материала
Наименование Материала
Количество Материала
Брак
Сектор хранения Материала
Описание Материала
Дата принятия Материала
Код принимаемого Материала
Количество принятого Материала
Сектор куда приняли Материал
Цена закупки Материала
Принимающий Материал
Дата выдачи Материала
Код выданного Материала
Количество выданного Материала
Сектор из которого выдан Материал
Цена продажи Материала
Выдающий Материал
Повторяющиеся группы не обнаружены. Повторяющаяся группа — это совокупность трёх и более одинаковых полей.
Вторая нормальная форма
Чтобы рассмотреть вопрос приведения отношений ко второй нормальной форме, необходимо дать пояснения к таким понятиям, как функциональная зависимость и полная функциональная зависимость.
Описательные реквизиты информационного объекта логически связаны с общим для них ключом, эта связь носит характер функциональной зависимости реквизитов.
Функциональная зависимость реквизитов — зависимость, при которой в экземпляре информационного объекта по определенному значению ключевого реквизита соответствует только одно значение описательного реквизита.
Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты.
В случае составного ключа вводится понятие функционально полной зависимости.
Функционально полная зависимость не ключевых атрибутов заключается в том, что каждый не ключевой атрибут функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа.
Отношение будет находиться во второй нормальной форме, если оно находится в первой нормальной форме, и каждый не ключевой атрибут функционально полно зависит от составного ключа.
Первый шаг второй нормальной формы — расстановка первичного ключа. Чтобы легче было установить первичный ключ в таблице, нужно сделать десять записей. Ключ, так же как и вся база, должен отличатся достаточностью и не избыточностью:
Название сектора
Код сектора*
Заведующий сектором
Номер договора*
Фамилия
Имя
Отчество
Дата рождения
Адрес по прописке
Номер телефона
Должность
Код материала*
Наименование материала
Количество материала
Брак
Сектор хранения материала
Описание материала
Дата принятия материала
Код принимаемого материала*
Количество принятого материала
Сектор куда приняли материал
Цена
Принимающий материал
Дата выдачи материала
Код выдаваемого материала*
Количество выданного материала
Сектор из которого выдан материал
Цена
Выдающий материал
Следующий шаг второй нормальной формы — соотношение не ключевых полей к ключевым.
Название сектора
Код сектора*
Заведующий сектором
Номер договора*
Фамилия
Имя
Отчество
Дата рождения
Адрес по прописке
Номер телефона
Должность
Код материала*
Наименование материала
Количество материала
Брак
Сектор хранения материала
Описание материала
Дата принятия материала
Код принимаемого материала*
Количество принятого материала
Сектор куда приняли материал
Цена
Принимающий материал
Дата выдачи материала
Код выдаваемого материала*
Количество выданного материала
Сектор из которого выдан материал
Цена
Выдающий материал
Третья нормальная форма
Понятие третьей нормальной формы основывается на понятии не транзитивной зависимости. Транзитивная зависимость наблюдается в том случае, если один из двух описательных реквизитов зависит от ключа, а другой описательный реквизит зависит от первого описательного реквизита.
Отношение будет находиться в третьей нормальной форме, если оно находится во второй нормальной форме, и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.
Для устранения транзитивной зависимости описательных реквизитов необходимо провести «расщепление» исходного информационного объекта. В результате расщепления часть реквизитов удаляется из исходного информационного объекта и включается в состав других (возможно, вновь созданных) информационных объектов.
Шаг 1 третьей нормальной формы — разбиение на таблицы:
Шаг 2 третьей нормальной формы — расстановка связей:
2. Описание модели базы данных
Логические модели баз данных:
- иерархическая;
- сетевая;
- реляционная.
Информационные модели баз данных:
- концептуальная модель;
- логическая (инфологическая модель данных «Сущность-связь»);
- реляционная модель.
База данных, описываемая в этой пояснительной записке, является реляционной базой данных.
Реляционная модель данных (РМД) — логическая модель данных, прикладная теория построения баз данных.
Реляционная модель данных включает следующие компоненты:
Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.
Аспект (составляющая) целостности — отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.
Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).
2.1 Описание таблиц
Таблица «секторы»:
|
Имя поля |
Тип данных |
Размер поля |
|
Название сектора |
TEXT |
25 |
|
Код сектора |
SMALLINT |
|
|
Заведующий сектором |
SMALLINT |
Таблица «Сотрудники»:
|
Имя поля |
Тип данных |
Размер поля |
|
Номер договора |
SMALLINT |
|
|
Фамилия |
TEXT |
25 |
|
Имя |
TEXT |
25 |
|
Отчество |
TEXT |
25 |
|
Дата рождения |
DATE |
|
|
Адрес по прописке |
TEXT |
25 |
|
Номер телефона |
TEXT |
17 |
|
Должность |
TEXT |
25 |
Таблица «Материалы»:
|
Имя поля |
Тип данных |
Размер поля |
|
Код Материала |
INT |
|
|
Наименование |
TEXT |
50 |
|
Количество |
SMALLINT |
|
|
Брак |
SMALLINT |
|
|
Сектор хранения |
SMALLINT |
|
|
Описание |
TEXT |
100 |
Таблица «Выдача»:
|
Имя поля |
Тип данных |
Размер поля |
|
Дата выдачи Материала |
DATE |
|
|
Код выданного Материала |
SMALLINT |
|
|
Количество выданного Материала |
SMALLINT |
|
|
Сектор |
SMALLINT |
|
|
Цена |
REAL |
|
|
Выдающий |
SMALLINT |
Таблица «Приемка»:
|
Имя поля |
Тип данных |
Размер поля |
|
Дата принятия Материала |
DATE |
|
|
Код принятого Материала |
SMALLINT |
|
|
Количество принятого Материала |
SMALLINT |
|
|
Сектор |
SMALLINT |
|
|
Цена |
REAL |
|
|
Принимающий |
SMALLINT |
2 Первичные ключи
Первичный ключ — каждая запись в столбце, на котором поставлен первичный ключ, должна обладать свойствами уникальности и минимальности, то есть это столбец, значения которого во всех строках различны. Первичные ключи могут быть логическими (естественными) и суррогатными (искусственными).
Суррогатный ключ представляет собой дополнительное поле в базе данных. Как правило, это порядковый номер записи.
В базе данных, описываемой в этой пояснительной записке, первичные ключи стоят в столбцах: «Код Материала» в таблице «Материал», «Код сектора» в таблице «Секторы»,
3 Связи между таблицами
Связи между таблицами бывают четырех видов:
- «Один к одному», когда каждой записи в главной таблице соответствует одна запись в подчиненной;
- «Один ко многим», когда каждой записи в главной таблице соответствует ноль или больше записей в подчиненной;
- «Многие к одному», когда нескольким записям в главной таблице соответствует одна в подчиненной;
- «Многие ко многим», когда произвольному числу записей в главной таблице соответствует такое же неопределенное число записей в подчиненной.
В базе данных, описываемой в этой пояснительной записке, используется только два вида связи — один ко многим и один к одному.
4 Типы таблиц
Таблицы — списки строк и столбцов, относящихся к конкретной области.
Типы таблиц:
- Сжатые;
- Динамические;
- Статические.
Характеристика для статических типов таблиц.
Это формат, принятый по умолчанию. Он используется, когда таблица не содержит столбцов VARCHAR, BLOB или TEXT.
Данный формат — самый простой и безопасный, а также наиболее быстрый при работе с дисками. Скорость достигается за счет простоты поиска информации на диске: в таблицах статического формата с индексом для этого достаточно всего лишь умножить номер строки на ее длину.
Кроме того, при сканировании таблицы очень просто считывать постоянное количество записей при каждом чтении с диска.
Если произойдет сбой во время записи в файл MyISAM фиксированного размера, myisamchk в любом случае сможет легко определить, где начинается и заканчивается любая строка. Поэтому обычно удается восстановить все записи, кроме тех, которые были частично перезаписаны. Отметим, что в MySQL все индексы могут быть восстановлены. Свойства статических таблиц следующие:
- Все столбцы CHAR, NUMERIC и DECIMAL расширены пробелами до ширины столбца;
- Очень быстрые;
- Легко кэшируются;
- Легко восстанавливаются после сбоя, так как записи расположены в фиксированных позициях;
- Не нуждаются в реорганизации (при помощи myisamchk), кроме случаев, когда удаляется большое количество записей и необходимо вернуть дисковое пространство операционной системе.
Для них обычно используется больше дискового пространства, чем для динамических таблиц.
Характеристика для динамических типов таблиц.
Данный формат используется для таблиц, которые содержат столбцы VARCHAR, BLOB или TEXT, а также если таблица была создана с параметром ROW_FORMAT=dynamic.
Это несколько более сложный формат, так как у каждой строки есть заголовок, в котором указана ее длина. Одна запись может заканчиваться более чем в одном месте, если она была увеличена во время обновления.
Чтобы произвести дефрагментацию таблицы, можно воспользоваться командами OPTIMIZE table или myisamchk. Если у вас есть статические данные, которые часто считываются/изменяются в некоторых столбцах VARCHAR или BLOB одной и той же таблицы, во избежание фрагментации эти динамические столбцы лучше переместить в другие таблицы. Свойства динамических таблиц следующие:
Все столбцы со строками являются динамическими (кроме тех, у которых длина меньше 4).
Перед каждой записью помещается битовый массив, показывающий, какие столбцы пусты (») для строковых столбцов, или ноль для числовых столбцов (это не то же самое, что столбцы, содержащие значение NULL).
Если длина строкового столбца равна нулю после удаления пробелов в конце строки, или у числового столбца значение ноль, он отмечается в битовом массиве и не сохраняется на диск. Строки, содержащие значения, сохраняются в виде байта длины и строки содержимого.
Обычно такие таблицы занимают намного меньше дискового пространства, чем таблицы с фиксированной длиной.
Для всех записей используется ровно столько места, сколько необходимо. Если размер записи увеличивается, она разделяется на несколько частей — по мере необходимости. Это приводит к фрагментации записей.
Если в строку добавляется информация, превышающая длину строки, строка будет фрагментирована. В этом случае для увеличения производительности можно время от времени запускать команду myisamchk -r. Чтобы получить статистические данные, воспользуйтесь командой myisamchk -ei tbl_name.
Восстановление после сбоя для таких таблиц является более сложным процессом, так как запись может быть фрагментированной и состоять из нескольких частей, а ссылка (или фрагмент) могут отсутствовать.
Предполагаемая длина строки для динамических записей вычисляется следующим образом:
+ (число столбцов+ 7) / 8
+ (число столбцов char)
+ размер числовых столбцов в упакованном виде
+ длина строк
+ (число столбцов NULL + 7) / 8
На каждую ссылку добавляется по 6 байтов. Динамические записи связываются при каждом увеличении записи во время обновления. Каждая новая ссылка занимает по крайней мере 20 байтов, поэтому следующее увеличение может произойти либо по этой же ссылке; либо по другой, если не хватит места. Количество ссылок можно проверить при помощи команды myisamchk -ed. Все ссылки можно удалить при помощи команды myisamchk -r.
Характеристика для сжатых типов таблиц.
Таблицы этого тип предназначены только для чтения. Они генерируются при помощи дополнительного инструмента myisampack (pack_isam для таблиц ISAM):
Все дистрибутивы MySQL, даже выпущенные до предоставления общедоступной лицензии MySQL, могут читать таблицы, которые были сжаты при помощи myisampack.
Сжатые таблицы занимают очень мало дискового пространства; таким образом при применении данного типа значительно снижается использование дискового пространства. Это полезно при работе с медленными дисками (такими как компакт-диски).
Каждая запись сжимается отдельно (незначительные издержки при доступе).
Заголовки у записей фиксированные (1-3 байта), в зависимости от самой большой записи в таблице. Все столбцы сжимаются по-разному. Ниже приведено описание некоторых типов сжатия:
Обычно для каждого столбца используются разные таблицы Хаффмана.
Сжимаются пробелы префикса.
Для хранения чисел со значением 0 отводится 1 бит.
Если у значений в целочисленном столбце небольшой диапазон, столбец сохраняется с использованием минимального по размерам возможного типа. Например, столбец BIGINT (8 байт) может быть сохранен как столбец TINYINT (1 байт) если все значения находятся в диапазоне от 0 до 255.
Если в столбце содержится небольшое множество возможных значений, тип столбца преобразовывается в ENUM.
Столбец может содержать сочетание указанных выше сжатий.
Для таблиц этого типа возможна обработка записей с фиксированной или динамической длиной.
Таблицы данного типа могут быть распакованы при помощи команды myisamchk.
Таблицы в базе данных «Склад строительных материалов» являются динамическим типом.
3. Создание базы данных
1 Создание таблиц
Для создания таблиц в MS Access использовались запросы в режиме SQL. Запрос — это набор инструкций, который можно использовать для обработки данных. Чтобы эти инструкции были выполнены, запрос следует запустить. Запрос не только возвращает результаты — которые можно сортировать, группировать и фильтровать — с помощью запроса можно также создавать, копировать, удалять и изменять данные.
Управляющий запрос — это особый тип запроса, при котором не происходит обработка данных. При выполнении запросов этого типа создаются новые, удаляются или изменяются объекты базы данных (Объекты базы данных. База данных Microsoft Access может содержать таблицы, запросы, формы, отчеты, страницы доступа к данным, макросы и модули. Проект Microsoft Access может содержать такие объекты как формы, отчеты, страницы макросы и модули.) <javascript:AppendPopup(this,’defDatabaseObjects_15′)>.
Запросы SQL нельзя открыть в режиме конструктора. Их можно открыть только в режиме SQL или запустить. Кроме управляющих запросов все остальные запросы SQL при выполнении открываются в режиме таблицы.
Для этого необходимо запустить Microsoft Office Access, создать новую базу данных, затем перейти на вкладку создание, затем нажать на кнопку в верхней панели «Конструктор запросов». Далее необходимо перейти в режим SQL. Переход осуществляется нажатием правой кнопкой мыши по вкладке открывшегося окна созданного запроса и выбором данного режима.
Чтобы создать таблицу, необходимо написать программный код на языке SQL. В данной базе данных присутствует 5 таблиц, это:
- Сектор;
- Сотрудники;
- Материалы;
- Приемка;
- Выдача.
Так как таблиц 5, поэтому и запросов соответственно тоже будет 5. Для первой таблицы код будет выглядеть так:TABLE Сектор
([Код сектора] SMALLINT PRIMARY KEY NOT NULL,
[Название сектора] TEXT (50),
[Заведующий сектором] SMALLINT).
Создание таблицы выполняется с помощью команды CREATE TABLE. Далее открываются круглые скобки. В квадратных скобках прописывается название поля, а затем тип вводимых данных и максимальное количество символов (если возможно ограничение).
Ключевым полем таблицы служит поле «Код сектора». Чтобы задать ключевое поле, после описания типа данных прописываем PRIMARY KEY. Так как ключевое поле не может быть нулевым, то нужно это указать командой NOT NULL.
Код таблицы «Сотрудники»:TABLE Сотрудники
([Номер договора] SMALLINT PRIMARY KEY NOT NULL ,
[Фамилия] TEXT(25) ,
[Имя] TEXT(25) ,
[Отчество] TEXT(25),
[Дата рождения] DATE,
[Номер телефона] TEXT(17) ,
[Должность] text(25)).
Код таблицы «Материалы»:TABLE Материалы
([Код Материала] INT PRIMARY KEY NOT NULL,
[Наименование Материалы] TEXT(50) ,
[Количество] SMALLINT ,
[Брак] SMALLINT,
[Сектор хранения] SMALLINT,
[Описание] TEXT(100)).
Код таблицы «Приемка»:TABLE Приемка
([Код товара] SMALLINT PRIMARY KEY NOT NULL ,
[Дата принятия] DATE ,
[Количество] SMALLINT ,
[Сектор] SMALLINT,
[Принял] SMALLINT,
[Цена] REAL).
Код таблицы «Выдача»:TABLE Выдача
([Код товара] SMALLINT PRIMARY KEY NOT NULL ,
[Дата выдачи] DATE ,
[Количество] SMALLINT ,
[Сектор] SMALLINT,
[Выдал] SMALLINT,
[Цена] REAL).
Создание моделей
Ядром любой базы данных является модель данных.Модель данных — совокупность структур данных и операций их обработки.
По способу установления связей между данными различают 3 модели данных:
- Иерархическую;
- Сетевую;
- Реляционную.
Иерархическая модель позволяет строить базы данных с древовидной структурой. В них каждый узел содержит свой тип данных. На верхнем уровне дерева в этой модели имеется один узел — «корень», на следующем уровне располагаются узлы, связанные с этим корнем, затем узлы, связанные с узлами предыдущего уровня и т.д. Каждый узел может иметь только одного предка. Основные достоинства иерархической модели — простота описания иерархических структур реального мира и быстрое выполнение запросов, соответствующих структуре данных, но они чаще содержат избыточные данные. Кроме того, не всегда удобно каждый раз начинать поиск нужных данных с корня, а другого способа перемещения по базе в иерархических структурах нет.
Указанный недостаток снят в сетевой модели, где, по крайней мере, теоретически возможны связи «всех информационных объектов со всеми».
Использование иерархической и сетевой моделей ускоряет доступ к информации в базе данных. Но поскольку каждый элемент данных должен содержать ссылки на некоторые другие элементы, требуются значительные ресурсы как дисковой, так и основной памяти ЭВМ. Недостаток основной памяти, конечно снижает скорость обработки данных. Кроме того, для таких моделей характерна сложность реализации системы управления базами данных.
Реляционная модель была разработана в начале 70-х годов Коддом. Простота и гибкость модели привлекли к ней внимание разработчиков. В 80-х годах она получила широкое распространение, и реляционные СУБД оказались промышленным стандартом.
Модель опирается на систему понятий реляционной алгебры, важнейшие из которых: таблица, строка, столбец, отношение, и первичный ключ, а все операции сводятся к манипуляциям с таблицами.
В реляционной модели информация представляется в виде прямоугольных таблиц. Каждая таблица состоит из строк и столбцов и имеет имя, уникальное внутри базы данных.
Таблица отражает объект реального мира — сущность, а каждая ее строка (запись) отражает один корректный экземпляр объекта — экземпляр сущности. Каждый столбец таблицы имеет уникальное для своей таблицы имя. Столбцы расположены в таблице в соответствии с порядком следования их имен при ее создании. Таблица не может иметь менее одного столбца.
В отличие от столбцов строки не имеют имен, порядок их следования в таблице не определен, а количество логически не ограничено. Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции. Хотя в файле у каждой строки имеется номер, он не характеризует строку. Его значение изменяется при удалении строк из таблицы. Логически среди строк не существует «первой» и «последней».
Реляционные системы исключили необходимость сложной навигации, поскольку данные представлены в них не в виде одного файла, а независимыми наборами, и для отбора данных используются операции реляционной алгебры — прикладной теории множеств.
В каждой таблице реляционной модели должен быть столбец или совокупность столбцов, значения которых однозначно идентифицируют каждую строку таблицы. Этот столбец или их совокупность и называется первичным ключом таблицы.
Если таблица удовлетворяет требованию уникальности первичного ключа, она называется отношением. В реляционной модели все таблицы должны быть преобразованы в отношения. Внешний ключ — это столбец (совокупность столбцов), значение которого однозначно характеризует значение первичного ключа другого отношения (таблицы).
Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором та же совокупность столбцов является первичным ключом.
Объектно-ориентированная модель баз начала создаваться в связи с появлением объектно-ориентированных языков программирования. Такого рода базы хранят методы классов, а иногда и постоянные объекты классов, что позволяет осуществлять беспрепятственную интеграцию между данными и их обработкой в приложениях.
Доминирование реляционной модели в современных СУБД определяется:
- Наличием развитой теории (реляционной алгебры);
- Наличием аппарата сведения других моделей данных к реляционной модели;
- Наличием специальных средств ускоренного доступа к информации;
- Наличием стандартизированного высокоуровневого языка запросов к БД, позволяющего манипулировать ими без знания конкретной физической организации БД во внешней памяти.
2 Заполнение таблиц
На этапе заполнения таблицы данными допускается изменять ее структуру, в частности добавлять новые поля (столбцы), удалять или изменять формат существующих полей, изменять формат данных в полях и записях таблицы.
Такие операции лучше всего делать с помощью контекстного меню.
С помощью контекстного меню можно также вставить поля в структуру таблицы. Для этого сначала необходимо выбрать столбец, перед которым нужно вставить новый, навести курсор на его название и выполнить кнопкой мыши правый клик. В контекстном меню выбрать «Вставить столбец», и в таблице появится новое поле с именем «Поле1». Имя нового поля можно изменить, через контекстное меню его заголовка, выбрав команду «Переименовать столбец». Для указания типа данных нового поля сначала необходимо выбрать это поле мышью, затем выбрать вкладку главного меню «Режим таблицы», на ленте в группе «Форматирование и тип данных» — параметр «Тип данных». В выпадающем списке выбрать нужный тип данных поля.
Для удобства работы с таблицей MS Access можно менять ширину столбцов, высоту строк, шрифт данных в ячейках таблицы и другие элементы ее форматирования. Можно также скрыть некоторые столбцы таблицы. Для этого в контекстном меню заголовка столбца выбрать «Скрыть столбец» — и он исчезнет с экрана, но при этом останется в структуре таблицы вместе с данными, которые в него внесены. Допускается также менять порядок столбцов в таблице. Для этого нужно нажать на заголовок столбца левой кнопкой мыши и, удерживая ее нажатой, перетянуть столбец в нужное место.
Таблицы могут содержать также данные особого рода, такие как фотографии и объекты других типов. Поля таблицы, содержащие такие данные, имеют, как правило, тип данных «Поле объекта OLE». Поля с типом данных «Вложение» используются для хранения нескольких файлов в одном поле, причем эти файлы могут быть разных типов.
4. Сценарий работы программы
Для построения сценария работы программы данной базы данных в общем было создано 12 отчетов — это:
- Просмотр данных всех сотрудников;
- Просмотр данных сотрудников по коду;
- Коды сотрудников;
- Поиск материала по коду;
- Поиск материала в секторе;
- Поиск материала по наименованию;
- Весь принятый материал;
- Поиск принятого материала по дате;
- Поиск принятого материала по коду;
- Весь выданный материал;
- Поиск выданного материала по дате;
- Поиск выданного материала по коду.
Для создания отчетов в MS Access использовались запросы. Запрос на выборку служит для создания подмножеств данных, которые можно использовать для получения ответов на определенные вопросы. При помощи такого запроса можно также передавать данные в другие объекты базы данных. После создания запроса на выборку его можно использовать по мере необходимости. Запрос на выборку — это объект базы данных, который служит для отображения данных в режиме таблицы (Режим таблицы. Окно, в котором данные из таблицы, формы, запроса, представления или хранимой процедуры выводятся в формате строк и столбцов. В режиме таблицы выполняется изменение значений полей, добавление или удаление данных и поиск данных.).
Запрос может получать данные из одной или нескольких таблиц, из существующих запросов или из комбинаций таблиц и запросов. Таблицы или запросы, используемые для получения данных, называются источниками записей.
Создание простых запросов на выборку при использовании мастера и при работе в режиме конструктора происходит одинаково. Для этого следует выбрать источник записей и поля, которые требуется включить в запрос. При необходимости можно задать условия для уточнения результатов запроса.
После создания запроса на выборку его следует выполнить, чтобы получить результаты. Чтобы выполнить запрос, достаточно открыть его в режиме таблицы. Впоследствии запрос можно использовать повторно по мере необходимости, например в качестве источника записей для формы, отчета или другого запроса.
Существует несколько типов запросов, каждый из которых предназначен для определенной цели. Например, запрос на выборку служит для отображения данных или для создания новой таблицы. Запрос на изменение служит для изменения данных в источнике данных. При запуске запроса с параметрами требуется задать условия.
В данном случае использовались запросы на выборку для отображения данных в отчетах.
Помимо отчетов, еще используются и формы для добавления и редактирования — это:
- Добавить нового сотрудника;
- Редактирование данных сотрудников.
Кнопочные формы:
- Главная кнопочная форма;
- Сотрудники;
- Материал;
- Приемка;
- Выдача.
На рисунке 4.1 представлен сценарий работы программы базы данных «Склад строительных материалов».
Рис. 4.1
5. Реализация сценария
1 Создание кнопочной формы
Создание «Главной кнопочной формы». Главная кнопочная форма создается с целью навигации по базе данных, т.е. она может использоваться в качестве главного меню БД. Элементами главной кнопочной формы являются объекты форм и отчетов. Запросы и таблицы не являются элементами главной кнопочной формы. Поэтому для создания кнопок Запросы и Таблицы на кнопочной форме можно использовать макросы.
Рисунок 5.1«Диспетчер кнопочных форм»
Сначала в окне базы данных создают макросы «Открыть Запрос» или «Открыть таблицу» с уникальными именами, а затем в кнопочной форме создают кнопки для вызова этих макросов.
Этот список может содержать только кнопочные формы. По нажатию на соответствующие кнопки можно создавать, изменять и удалять формы. Используя кнопку Создать необходимо добавить новые, подчиненные главной, кнопочные формы: Главная кнопочная форма, Выдача, Материал, Приемка, Сотрудники.
При нажатии на кнопку Создать открывается окно Создание, в котором нужно указать имя создаваемой кнопочной формы.
Рисунок 5.2«Окно «Создание»
После добавления всех кнопочных форм в списке Страницы кнопочной формы должно быть пять форм:
