Использование MS SQL Server Management Studio для работы с объектами базы данных

3.1. Описание учебной базы данных «Realizations of goods» (Реализация товаров)

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

Исходя из анализа предметной области, можно выделить три типа сущностей – ТИП ТОВАРА, ТОВАРЫ, РЕАЛИЗАЦИЯ.

Определим атрибуты этих сущностей. К объекту ТИП ТОВАРА (таблица Type_goods) относятся такие характеристики, как название вида товара. К объекту ТОВАРЫ (таблица Goods) – название товара, цена приобретения, цена реализации. Тип сущности РЕАЛИЗАЦИЯ (таблица Realizations) может быть охарактеризован такими признаками, как дата и количество проданного товара.

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

Для таблицы ТИП ТОВАРА введем простой первичный ключ (PK - Primary Key) по полю id_type_goods, под которым можно понимать, например, артикул вида товара. В таблице ТОВАРЫ введем простой первичный ключ по полю id_goods, под которым можно понимать, например, артикул товара или любой другой атрибут, однозначно определяющий каждый товар.

Для таблицы РЕАЛИЗАЦИЯ первичным ключом является составной ключ, состоящий из совокупности полей date_real (дата и время реализации), id_goods (код товара) и amount (количество проданного товара), т.к. эта совокупность с некоторыми ограничениями однозначно определяет реализацию товара. В качестве первичного ключа можно было бы выбрать простой ключ из одного поля (например, порядковый номер реализации), но для иллюстрации конструкций языка SQL остановимся на составном первичном ключе.

Установим связи между объектами (таблицами). Один покупатель может неоднократно покупать товары. Поэтому между таблицами ТОВАРЫ и РЕАЛИЗАЦИЯ имеется связь "один–ко–многим" по полю id_goods. В таблице РЕАЛИЗАЦИЯ данное поле определено как внешний ключ (FK- Foreign Key).

Каждый вид товара может содержать несколько наименований товара. Поэтому между таблицами ТИП ТОВАРА и ТОВАРЫ имеется связь "один–ко–многим" по полю id_type_goods. В таблице ТОВАРЫ данное поле определено как внешний ключ.

Структура рассматриваемых таблиц базы данных «Реализация товаров» (Realizations of goods) приведена соответственно в таблицах 6-8, где PK- первичный ключ (Primary Key); FK- внешний,подчиненный (иностранный) ключ (Foreign Key).

Таблица 6. Структура таблицы "Type_goods"

№	Тип ключа	имя поля	Описание	Тип
	PK	id_type_goods	код вида товара	Int
		name_type_goods	название вида товара	Char(50)

Таблица 7. Структура таблицы "Goods"

№	Тип ключа	имя поля	Описание	Тип
	PK	id_goods	код товара	Int
	FK	id_type_goods	код вида товара	Int
		name_goods	название товара	Char(50)
		price_acq	цена приобретения	Float
		price_real	цена реализации	Float

Таблица 8. Структура таблицы "Realization"

№	Тип ключа	имя поля	Описание	Тип
	PK	date_real	дата и время реализации	DateTime
	PK,FK	id_goods	код товара	Int
	PK	amount	кол-во реализаций (шт, кг)	Float

В качестве имени поля допустимы латинские буквы, цифры и знак «_». В случае использования знака пробел, имя поля автоматически заключается системой в квадратные скобки, что несколько увеличивает длину, поэтому вместо пробела рекомендуется использовать знак «_». Этот прием довольно широко распространен и часто используется, например, при написании URL адресов.

Длину поля «name_type_goods» и «name_goods» необходимо установить в 50 символов вместо 10, установленных по умолчанию, потому что в это поле может быть занесена длинная строка. Например, в строке «Мясные и рыбные продукты» количество символов более 10. Заметим, что язык SQL предоставляет возможность использования большого количества типов полей (см. таблицу 2).

Например, для поля «name_type_goods» можно было использовать следующие типы полей: nchar, varchar, char, а для поля «amount» - тип float либо real. Типы полей определяются разработчиком на стадии проектирования базы данных, и в дальнейшем они не могут меняться. В поле "amount» установлен вещественный тип, а не целочисленный. Это сделано для возможности вводить в данное поле дробное значение. Например, при реализации не штучного товара, когда количество реализаций определяется в кг и может быть не целым числом. В нашем случае типы полей были выбраны из допустимого диапазона с учетом исключения проблем, связанных с дальнейшим использованием базы данных с помощью MS-VBasic.

Связи между таблицами осуществляются по типу «один-ко-многим». Поэтому необходимо установить связь PK главной таблицы с одноименным FK детальной таблицы. Следует обратить внимание, что имена полей в связанных таблицах совпадают, но это совсем не обязательно, в нашем случае мы это сделали для удобства, но типы полей (как правило, Int), обязательно должны совпадать.

В таблице "Realization" необходимо установить в качестве первичного ключа не одно поле, а три (это сделано для демонстрации возможностей языка SQL). Однако, при этом не будет возможности ввести запись в таблицу "Realization", где сочетания значений всех этих трех полей будет повторяться. Иными словами, нельзя продать один и тот же товар, в том же количестве в течение одного дня. Чтобы избежать коллизий, достаточно ввести дополнительно, например, в поле «date_real», не только дату, но еще и время реализации (час, мин, сек).

Структура таблицы "Realization" вполне корректно может выглядеть следующим образом (таблица 9).

Таблица 9. Второй вариант структуры таблицы "Realization"

№	Тип ключа	Имя поля	Описание	Тип
	PK	id_real	код реализации	Int
		date_real	дата и время реализации	DateTime
	FK	id_goods	код товара	Int
		Amount	кол-во реализаций (шт,кг)	Float

Обратите внимание, что в таблице введено дополнительное поле «id_real», которое потом сделано ключевым. Данное поле в дальнейшем не будет учавствовать в нашем проекте, но, тем не менее, оно вводиться для дальнейшей модернизации проекта. Кроме того, «SQL server» рекомендует все записи делать уникальными, в случае их дальнейшей идентификации.

Тем не менее, можно было не вводить это поле, как впрочем, и в предыдущей таблице (таблица 8) не делать ключ PK из трех полей. Как правило, для ключевых полей редко используют текстовые поля, а, тем более, несколько полей. Но, тем не менее, это вполне допустимо, а иногда и оправдано. Поэтому, в дальнейшем для демонстрации возможностей SQL будут использоваться таблицы 6,7,8. Функциональная схема зависимостей между таблицами приведена на рисунке 5.

Таблица "Type_goods" Таблица "Goods" Таблица "Realization"

Рис. 5. Схема зависимостей между таблицами базы данных «Реализация товаров»

Дата добавления: 2015-07-08