Разработка логической структуры БД

Разработка структуры таблиц БД

Определение логических связей между объектами БД

Между выделенными информационными объектами обязательно существуют логические связи: без этого нет БД.

Мы используем один тип связи: один ко многим (1:М). Связь 1:М имеет место, когда каждый экземпляр (запись) первого объекта соотносится с несколькими экземплярами (записями) второго объекта, но каждый экземпляр второго – только с один экземпляром первого. В этом типе связи первый объект является Главным, а второй Подчиненным.

Определим типы связи между нашими информационными объектами:

Таблица 1

Главный объект	Подчиненный объект	Тип связи	Пояснения к связям
Изделия	Заявки	1:М	По каждому коду (виду) изделия может быть несколько заявок
Изделия	Отгрузка	1:М	По каждому коду изделия может быть несколько отгрузок
Изделия	Реализация	1:М	По каждому ходу изделия может быть несколько оплат
Заказчик	Заявки	1:М	Каждый заказчик многократно заказывает готовую продукцию.
Заказчик	Отгрузка	1:М	Каждому заказчику может быть несколько отгрузок.
Заказчик	Реализация	1:М	От каждого заказчика может поступить несколько платежей

На этом этапе выделенные информационные объекты должны быть представлены реляционными таблицами.

Как уже отмечалось, таблица является аналогом (не копией)документа: во-первых, она может создаваться на основе нескольких документов; во-вторых, может быть изменен состав показателей по отношению к документу; в-третьих, таблица может вообще не иметь аналога в лице документа и создаваться как новый информационный объект. Так, в таблицу Отгрузка будет добавлен показатель Прибыль, в таблицу Реализация – показатель недооплата и т. д.

Информационная модель формирования таблиц БД представлена на рис.1.

Документы –

источники формиро-

вания таблиц

Реляционные

таблицы

Рис. 1. Информационная модель формирования таблиц БД

«Реализация готовой продукции»

1. Классификатор изделий (НСИ).

2. Классификатор заказчиков (НСИ).

3. Заявки (Оперативная информация).

4. Товарно-транспортная накладная (Оперативная информация).

5. Полная фактическая себестоимость (Оперативная информация).

6. Счёт-фактура (Оперативная информация).

7. Таблица Изделия.

8. Таблица Заказчики.

9. Таблица Заявки.

10. Таблица Отгрузка.

11. Таблица Реализация.

Реляционная таблица двумерна, т.е. представлена полями и записями.

Их аналогами в структуре обычных документов соответственно являются колонки (таблицы) и строки. Записьсодержит и хранит данные о конкретном экземпляре информационного объекта. Каждоеполе несет в себе только одну характеристику конкретного информационного объекта (аналогично колонке обычного документа). Кроме того, каждое поле наделено рядом свойств, которые определяют возможности БД. Ключевые реквизиты образуют уникальный ключтаблицы.

Определим структуру таблиц, т.е. состав полей,и выявим в них ключевые поля:

- Изделия: № п/п, код изделия (ключевое поле), наименование изделия, единица измерения, плановая себестоимость.

- Заказчик: № п/п, код заказчика (ключевое поле), наименование заказчика, процент штрафа за просрочку платежа, счёт банка, корреспондентский счёт, субсчёт, аналитический счёт, адрес, телефон.

- Заявки: № п/п (ключевое поле), код заказчика, код изделия, номер заказа, плановая дата поставки, заявленное количество, недопоставка.

- Отгрузка: № п/п (ключевое поле), код заказчика, код изделия, дата отгрузки, отгруженное количество, полная фактическая себестоимость, стоимость отгруженного, процент штрафа за просрочку отгрузки, прибыль.

- Реализация: № п/п (ключевое поле), код заказчика, код изделия, дата реализации, цена договорная, оплаченное количество, оплата, недоплата за поставку.

В каждой таблице в качестве ключавыбрано поле, данные в котором повторяться не могут. Так, свой индивидуальный код присваивается: таблице Изделия– каждому виду изделий, Заказчики – каждому потребителю изделий.

В оперативных таблицах Заявки, Отгрузка и Реализация вообще нет полей, которые можно было бы использовать как ключевые, т.к. по каждому виду изделия может быть несколько заявок, отгрузок и платежей от нескольких заказчиков. Поэтому в таблицы было введено по дополнительному полю НПП (№ п/п) типа данных Счетчик, которое не может содержать повторяющихся данных по определению и поэтому рассматривается как ключевое.

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

Имя поля – это форма обращения к данным этого поля. Оно уникально и записывается в виде комбинаций из букв, цифр, символов (кроме:.!,” [ ] ). Максимальная длина – 64 символа.

Тип данных определяет тип поля:

- Текстовый – устанавливается по умолчанию, хранит текст и цифры, не участвующие в расчете. Максимальная длина 255 символов;

- поле Мемо – хранит текстовые данные длиной до 65535 символов;

- Числовой – для хранения действительных чисел, используемых в математических вычислениях;

- Дата/время - для хранения календарных дат и текущего времени. Допускают ввод дат из диапазона от100 до 9999год;

- Денежный – для хранения денежных сумм. Могут быть заменены полями числовыми, но для записи денежных значений более удобны (например, при округлении);

Длина поля – 4 байта;

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

- Логический – для хранения логических данных, которые могут принимать только одно из двух значений: ДА/НЕТ, Истина/Ложь, Вкл/Выкл; длина поля – 1 бит;

- Поле объекта OLE – тип данных, предназначенный для хранения объектов, связанных или внедренных в таблицу ACCESS. Длина поля – 1 Гбайт;

- Гиперссылка – в полях этого типа хранятся гиперссылки, представляющие собой путь к файлу на жёстком диске или адрес в сети Интернет.

Для каждого поля в зависимости от типа данных задаются Свойстваполя: Общие и Подстановка.

Общие свойства поля:

- Размер поля – определяет максимальную длину текстового или числового поля;

- Формат поля – устанавливает формат отображения данных в Форме и Запросе;

- Число десятичных знаков – определяет количество разрядов в дробной части десятичного числа;

- Маска ввода – определяет маску данных при вводе;

- Подпись – содержит надпись, которая выводится рядом с полем в Таблице, Форме и Отчёте;

- Значение по умолчанию – содержит значение, которое устанавливается в соответствующем поле таблицы по умолчанию;

- Условие на значение – определяет множество значений, которые пользователь может вводить в это поле при заполнении Таблицы;

- Сообщение об ошибке – определяет сообщение, которое появляется на экране при вводе недопустимого значения;

- Обязательное поле – установка, указывающая на то, что это поле обязательно следует заполнить; принимает одно из двух значений: ДАили НЕТ;

- Пустые строки - установка определяет, допускается ли ввод в данное поле пустых строк;

- Индексированное поле – определяет простые индексы для ускорения поиска (поле первичного ключа индексируется автоматически); принимает одно из трех значений: нет, да (совпадения не допускаются), да (совпадения допускаются);

- Сжатие Юникод – указывает, используется ли кодировка Unicode для данного поля.

Свойства подстановки: во-первых, задает для поля тип элемента управления: Поле, Список, Поле со списком; во-вторых, указывает источник формирования Списка или Поля со списком; в-третьих, позволяет автоматизировать ввод данных в поле таким образом, чтобы не вводя их вручную, выбирать из раскрывшегося списка.

Теперь для каждой таблицы дадим описание свойств ее полей.

Изделия (НСИ) Таблица 2

Реквизит	Имя поля	Ключ	Тип данных	Размер поля	Подпись поля	Обяза-тельное поле	Индексированное поле
№ п/п	НПП		Счетчик	Длинное целое	№ записи	-	нет
Код изделия	КИ	Да	Текстовый		Код изделия	Да	Да (совпадения не допускается)
Наименование изделия	НИ		Текстовый		Наименование изделия	Нет	Нет
Единицы измерения	ЕИ		Текстовый		Единица измерения	Нет	Нет
Плановая себестоимость	ПСС		Денежный		Плановая себестоимость	Нет	Нет

Заказчики (НСИ) Таблица 3

Реквизит	Имя поля	Ключ	Тип данных	Размер поля	Подпись поля	Обязате-льное поле	Индексирован-ное поле
№ п/п	НПП		Счетчик	Длинное целое	№ записи	-	нет
Код заказчика	КЗак	Да	Текстовый		Код заказчика	да	Да (совпадение не допускается)
Наименование заказчика	НЗак		Текстовый		Наименование заказчика	Нет	Нет
Счет банка	БСч		Текстовый		Счет банка	Нет	Нет
Корреспондент-ский счет	КСч		Текстовый		Корреспондент-ский счет	Нет	Нет
Субсчет	ССч		Текстовый		Субсчет	Нет	Нет
Аналитический счет	АСч		Текстовый		Аналитический счет	Нет	Нет
Адрес	Адр		Текстовый		Адрес	Нет	Нет
Телефон	Тел		Текстовый		Телефон	Нет	Нет

Заявки (оперативная) Таблица 4

Реквизит	Имя поля	Ключ	Тип данных	Размер поля	Подпись поля	Обязательное поле	Индексирован-ное поле
№ п/п	НПП	Да	Счетчик	Длинное целое	№ записи	-	Да (совпадение не допускается)
Код заказчика	КЗак		Текстовый		Код заказчика	Да	Да (совпадение допускается)
Код изделия	КИ		Текстовый		Код изделия	Да	Да (совпадение допускается)
№ заказа	НомЗак		Текстовый		№ заказа	Нет	Нет
Дата поставки плановая	ДПП		Дата/время	Краткий формат даты	Дата поставки плановая	Нет	Нет
Количество заявленное	КолЗ		Числовой	Целое	Количество заявленное	Нет	Нет

Отгрузка (оперативная) Таблица 5

Реквизит	Имя поля	Ключ	Тип данных	Размер поля	Подпись поля	Обяза-тельное поле	Индексированное поле
№ п/п	НПП	Да	Счетчик	Длинное целое	№ записи	-	Да (совпадение не допускается)
Код заказчика	КЗак		Текстовый		Код заказчика	Да	Да (совпадение допускается)
Код изделия	КИ		Текстовый		Код изделия	Да	Да (совпадение допускается)
№ заказа	НомЗак		Текстовый		№ заказа	Нет	Нет
Дата отгрузки	ДОтгр		Дата/время	Краткий формат даты	Дата отгрузки	Нет	Нет
Количество отгруженное	КолОтгр		Числовой	Целое	Количество отгруженное	Нет	Нет
Стоимость отгруженного	СтОтгр		Числовой	Длинное целое	Стоимость отгруженного	Нет	Нет
Процент штрафа за задержку отгрузки	ПШО		Числовой	Одинар-ное с плаваю-щей точкой	Процент штрафа за задержку отгрузки	Нет	Нет
Фактическая себестоимость	ФСС		Денежный		Фактическая себестоимость	Нет	Нет
Прибыль	Приб		Денежный		Прибыль	Нет	Нет

Реализация (оперативная) Таблица 6

Реквизит	Имя поля	Ключ	Тип данных	Размер поля	Подпись поля	Обязательное поле	Индексированное поле
№ п/п	НПП	Да	Счетчик	Длинное целое	№ записи	-	Да (совпадение не допускается)
Код заказчика	КЗак		Текстовый		Код заказчика	Да	Да (совпадение допускается)
Код изделия	КИ		Текстовый		Код изделия	Да	Да (совпадение допускается)
№ заказа	НомЗак		Текстовый		№ заказа	Нет	Нет
Дата реализации	ДР		Дата/время	Краткий формат даты	Дата реализации	Нет	Нет
Цена договорная	ЦДог		Денежный		Цена договорная	Нет	Нет
Количество оплаченное	КолОпл		Числовой	Целое	Количество оплаченное	Нет	Нет
Оплата	Опл		Денежный		Оплата	Нет	Нет

После описания таблиц выполняется последний этап проектирования – разработка взаимосвязи между таблицами, составляющими БД - «Реализация готовой продукции».Результатом выполнения этапа будет схема, называемая логической структурой БД (см. рис. 2).

Рис. 2. Логическая структура БД «Реализация готовой продукции»

Как отмечалось выше, при создании БД имеет место форма связи между таблицами "один – ко многим".

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

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

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

БД создается как новая, т.е. «с нуля», что определяет стадии формирования:

· формирование структуры таблиц;

· загрузка таблиц;

· создание схемы данных.

Дата добавления: 2015-06-27