Курсовая работа (т): Склад строительных материалов

Таблица «Приемка»:

.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-х годах она получила широкое распространение, и реляционные СУБД оказались промышленным стандартом.

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

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

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

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

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

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

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

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

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

Доминирование реляционной модели в современных СУБД определяется:

Наличием развитой теории (реляционной алгебры);

Наличием аппарата сведения других моделей данных к реляционной модели;

Наличием специальных средств ускоренного доступа к информации;

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