Пример проектирования базы данных (БД)

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

Таблица 2

Исходная форма базы данных.

№	Дата	Покупатель	Цех	Оплачено или нет	Товар	Коли-чест- во	Цена, руб.	Товар	Коли-чест-во	Цена, руб.	Сум-ма, руб.
	20.04	Депо «Самара»	ТР-3	Да	Краска зелёная			Краска серая
	15.04	Депо «Самара»	Колес-ный	Да	Поводок шестерни
	7.05	Депо «Самара»	Авто-матный	Нет	Манжета резиновая
	9.05	Депо «Самара»	Аппа-ратный	Да	Медь листовая			Прово-лока медная

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

Таблица 3

Структура исходной базы данных

№/№	Имя поля	Тип данных*	Объем информации** (кол-во символов)
	Num	N
	Date	D
	Client	C
	PODR	C
	OPL	L
	T1	C
	K1	N
	P1	N
	T2	C
	K2	N
	P2	N
	Sum	N

Прим.* N – число, D – дата и время, C – строка символов, L – логический тип

**Объем информации зависит от типа данных: для N – количество разрядов числа (изменяемо), D – дата и время – 10 символов (неизменно), С – количество символов (изменяемо), L – два значения y/n (ДА/НЕТ).

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

№   Num	Дата   Date	Покупатель     Client	Цех   PODR	Оплачено или нет OPL	Товар   T1	Коли-чест- Во   K1	Цена, руб.     P1	Товар   T2	Коли-чест- Во   K2	Цена, руб.     P2
N4	D10	C25	C30	L2	C20	N5	N7	C20	N5	N7

Рис.1.

Как видно из табл.2 для хранения одной накладной необходимо всегда одно и тоже количество памяти компьютера, независимо от того, один или три

товара проданы по этой накладной. В тоже время отпуск четырёх товаров по одной накладной невозможен по причине узости структуры (табл.3). Для решения этой проблемы: разобьем базу данных на две таблицы (назовем Zagolovok и Sodergimoe) и свяжем их по ключу.

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

При просмотре накладных система производит поиск и выводит на экран не цифру, а найденное значение в таблице клиентов.

Таблица 4 Таблица 5

Zagolovok Sodergimoe

№	Дата	Клиент	Цех	Оплачено или нет		№	Товар	Количество	Цена	Сумма
	20.04	Депо «Самара»	ТР-3	Да		Краска зелёная
	Краска серая
	Уголок
	25.04	Депо «Самара»	Колесный	Да		Поводок шестерни
	7.05	Депо «Самара»	Автоматный	Нет		Манжета резиновая
	9.05	Депо «Самара»	Аппаратный	Да		Медь листовая
	проволока медная

Таблица 6.

Структура таблицы Zagolovok.

№/№	Имя поля	Тип данных	Объем информации (кол-во символов)
	NUM	N
	DATE	D
	Client	C
	PODR	C
	OPL	L

Таблица 7.

Структура таблицы Sodergimoe.

№/№	Имя поля	Тип данных	Объем информации (кол-во символов)
	NUM	N
	T	C
	K	N
	C	N
	SUM	N

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

N	NUM	(1)®(2)   ®(5)     ®(4)	N	NUM	®(3)
C	T	N	CODE
C	NAME
N	K
N	C
N	SUM
D	DATE
N	CLIENT	N	CODE
C	NAME
C	ADDR
C	BANK
N	PODR	N	CODE
C	NAME
L	OPL

Рис.1 Преобразованная структура базы данных

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

(1) - база данных по заголовкам накладных;

(2) - база данных по содержимому;

(3) - база данных по продукции;

(4) - база данных по подразделениям;

(5) - база данных по клиентам.

Ключами для поиска в таблицах являются:

- в (2) – поле NUM;

- в (3),(4),(5). – поле CODE.

Три этапа нормализации базы данных:

1) Отсутствие повторяющихся полей, т.е. все значения должны быть неповторяющимися. Для этого мы создали (2). Каждое поле должно содержать минимум информации для поиска в других базах – поле CLIENT в (1) содержит ссылку на (5), в которой и содержится вся информация о клиенте и т.д.

2) Каждый столбец должен зависеть от первичного ключа. Поле CLIENT в (1) является критерием поиска в (5) по ключу CODE.

3) Все первичные ключи должны зависеть только от первичных полей. Поле CODE в (3),(4) и (5) является первичным полем и по нему в этих таблицах строится ключ (первичный) т.е. значения в этом столбце не повторяются. В таблице (2) поле NUM имеет другое назначение. В отличие от первичного ключа – это вторичный ключ - просто порядок сортировки данных. По нему фильтруются данные для отбора. Программа как бы узнает те записи, в которых это поле имеет другое значение.

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