Проектирование реляционной базы данных

Проектирование реляционной базы данных

База данных Access является реляционной базой данных. Такая база данных состоит из взаимосвязанных реляционных таблиц. На этапе проектирования базы данных для выбранной предметной области должна быть определена логическая структура базы данных. Проект логической структуры БД устанавливает состав реляционных таблиц, их структуру и логические связи между таблицами. При формировании структуры каждой таблицы определяется совокупность полей (столбцов), для каждого из которых определяется тип, размер данных и другие свойства. Для таблицы должен быть указан уникальный ключ, который может состоять из одного или нескольких полей. При проектировании базы данных, отвечающей требованиям нормализации, между таблицами определяются логические связи с типом отношений "один-ко-многим" (1: М). Такие связи позволят осуществлять в Access автоматическое поддержание связной целостности и непротиворечивости данных в базе.

Построение информационно-логической модели данных

Информационно-логическая модель (ИЛМ) отображает данные предметной области в виде совокупности информационных объектов (ИО) и связей между ними. Эта модель представляет данные, подлежащие хранению в базе данных. Каждый информационный объект в модели данных должен иметь уникальное имя.

Информационные объекты

Информационный объект — это информационное описание некоторой сущности предметной области: реального объекта, процесса, явления или события. Информационный объект является совокупностью логически взаимосвязанных реквизитов, представляющих качественные и количественные характеристики сущности. Примерами сущностей являются: товар, поставщик, заказчик, поставка, отгрузка, сотрудник, отдел, студент, преподаватель, кафедра и т. п. Информационный объект имеет множество реализаций — экземпляров объекта. Например, каждый экземпляр информационного объекта ТОВАР содержит значения реквизитов по товару определенного наименования. Экземпляр объекта должен однозначно определяться среди всего множества экземпляров, т. е. идентифицироваться значением уникального (первичного) ключа информационного объекта. Уникальность ключа означает, что любое значение ключа не может повториться в каком-либо другом экземпляре объекта. Простой ключ состоит из одного реквизита. Составной ключ — из нескольких реквизитов. Таким образом, реквизиты информационного объекта подразделяются на ключевые и описательные, которые являются функционально зависимыми от ключа.

ЗАМЕЧАНИЕ

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

Таблица 2.1. Пример идентификации поставок товаров

Реквизит	Код товара	Код поставщика	Срок поставки	Количество поставки	Результат в базе данных
Роль в функциональной зависимости	Ключевой	Ключевой		Зависимый
	Идентификатор поставки
Поставка 1	Т1	П1	Февраль	10	Введена
Поставка 2	Т1	П1	Апрель	20	Не введена

 

При графическом изображении модели данных каждый информационный объект представляется прямоугольником с обозначением его имени и идентификатора — ключа. Пример такого изображения для информационных объектов ТОВАР и ПОСТАВКА показан на рис. 2.2. Здесь KOД_Т (код товара) — простой ключ объекта ТОВАР, а KOД_T + KПОСТ (код поставщика) + СРОКП (срок поставки) — составной ключ объекта ПОСТАВКА.

ТОВАР

КОД_Т

ПОСТАВКА

КОД_Т + КПОСТ + СРОКП

 

Рис. 2.2. Пример графического изображения информационных объектов с простым и составным ключами

Требования нормализации

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

· информационный объект должен содержать уникальный идентификатор — ключ;

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

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

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

· каждый описательный реквизит должен зависеть от ключа нетранзитивно, т. е. не должен зависеть через другой промежуточный реквизит.

ЗАМЕЧАНИЕ

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

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

 

Структурирование информации

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

· реквизит — простейшая структурная единица информации, неделимая на смысловом уровне, отражающая количественную или качественную характеристику сущности (объекта, процесса и т. п.) предметной области. Можно выделить реквизиты-признаки и реквизиты-основания:

• реквизит-признак позволяет выделить (идентифицировать) объект из множества однотипных объектов (как правило, символьное представление);

• реквизит-основание содержит количественную характеристику объекта, процесса или другой сущности, определяющую их состояние (как правило, числовое значение).

Например, в плане поставок товаров реквизиты-признаки идентифицируют поставку, а реквизиты-основания определяют количество поставляемого товара, его стоимость;

· составная единица информации (СЕИ) — логически взаимосвязанная совокупность реквизитов. Примером составной единицы информации может служить документ. Семантика и размещение реквизитов в форме документа определяют роль реквизитов в структуре информации, содержащейся в документе.

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

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

Функциональную зависимость реквизитов удобно изобразить графически в виде линий со стрелками, идущих от ключевого (определяющего) реквизита к описательному реквизиту (определяемому). Ключевой реквизит обычно отмечается особо. Функциональную зависимость можно отображать непосредственно в таблице, где представлен состав реквизитов каждого документа. Это показано на примере реквизитов документа "Справочник товаров" (рис. 2.3), где каждый из описательных реквизитов однозначно определяется ключевым реквизитом Код товара.

 

Наименование реквизита	Имя реквизита	Функциональные зависимости
Код товара	KODT
Наименование	NAIM
Цена за единицу	CENA
Единица измерения	EI

 

Рис. 2.3. Функциональная зависимость реквизитов документа "Справочник товаров"

ЗАМЕЧАНИЕ

Обычно при следовании приведенным правилам сразу оказываются выделенными объекты, играющие роль связки между объектами, находящимися в отношении "многие-ко-многим" (М: N). Соответственно, в модели можно ограничиться рассмотрением только одно-многозначных связей.

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

Выделение информационных объектов на примере предметной области "Поставка товаров"

Рассмотрим выделение информационных объектов на примере предметной области "Поставка товаров".

Описание предметной области

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

· справочную информацию о поставляемых товарах;

· справочную информацию о покупателях (заказчиках);

· справочную информацию о складах предприятия, где хранится товар;

· данные о плановых поставках товаров;

· оперативно-учетные данные об отгрузках товаров со складов покупателям.

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

Справочная информация содержится в документах "Справочник товаров", "Справочник покупателей", "Справочник складов". На рис. 2.4–2.6 приведены формы этих документов.

 

СПРАВОЧНИК ТОВАРОВ, ПОСТАВЛЯЕМЫХ ФИРМОЙ

Код товара	Наименование	Единица измерения	Цена НДС

Рис. 2.4. Форма документа "Справочник товаров, поставляемых фирмой"

 

 

СПРАВОЧНИК СКЛАДОВ ФИРМЫ

Фирма /код, наименование/

Код склада	Наименование	Адрес	Отв. лицо

Рис. 2.5. Форма документа "Справочник складов фирмы"

 

СПРАВОЧНИК ПОКУПАТЕЛЕЙ ФИРМЫ

Код	ИНН	Наименование	Адрес	Тел.	№ расч. Счета	Банк

Рис. 2.6. Форма документа "Справочник покупателей фирмы"

Информация о планируемых поставках содержится в договорах. Форма договора приведена на рис. 2.7.

Договор

"_____" ______________ 202__ г.

 

Поставщик                                                                                                                  Покупатель

ИНН, код__________________	ИНН, код__________________
Наименование_____________	Наименование_____________
Адрес_____________________	Адрес_____________________
Телефон___________________	Телефон___________________
Банк______________________	Банк______________________
расчетный счет_____________	расчетный счет_____________

 

 

Код товара	Наименование	Единица измерения	Цена	Срок поставки (месяц)	Мин. партия поставки	Кол-во	Сумма

Сумма всего __________

 

Рис. 2.7. Форма договора на поставку товаров

 

Учетная информация с данными по фактической отгрузке товаров покупателю со склада фирмы в соответствии с договорами содержится в расходных накладных (рис. 2.8).

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

 

Накладная №_____

"_____" ______________ 202__ г.

Поставщик	Покупатель
ИНН, код_________________	ИНН, код________________
наименование	наименование
Склад-грузоотправитель
Код___________________________
Наименование____________________

 

Договор №___от «___» _________202___г.

Код товара	Наименование	Единица измерения	Цена	Ставк НДС	Количество	Сумма

Сумма всего __________

Отпустил_____________________                             ФИО материально отв.лица________________

Рис. 2.8. Форма накладной с данными по фактической отгрузке товаров

ЗАМЕЧАНИЕ

ИНН можно использовать в качестве альтернативного ключа и создать по нему уникальный индекс в базе данных.

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

Таблица 2.3. Группировка реквизитов по информационным объектам ТОВАР и ПОКУПАТЕЛЬ

Реквизиты объекта	Признак ключа	Имя информационного объекта	Семантика объекта
КОД_ТОВ	Простой уникальный	ТОВАР	Сведения о поставляемых товарах
НАИМ_ТОВ  ЦЕНА  ЕИ СТАВКА_НДС
КОД_ПOK	Простой уникальный	ПOKУПАТЕЛЬ	Сведения о покупателях фирмы
ИНН  НАИМ_ПОК АДРЕС_ПОК ТЕЛ НОМ_РСЧ  БАНК

 

 

Анализ документа "Справочник складов фирмы". Определим функциональные зависимости между реквизитами документа "Справочник складов фирмы", предварительно составив их перечень (рис. 2.10). Присвоим реквизитам сокращенные обозначения — имена. Все описательные реквизиты склада: Наименование склада (НАИМ_СК), Адрес (АДРЕС_СК), Отв. лицо (ОТВ_ЛИЦО) однозначно определены Кодом склада (КОД_СК), который поэтому является ключевым. Обратим внимание, что в общей части документа указан Код фирмы (КОД_Ф) — один для всего списка складов. Очевидно, каждому значению кода склада соответствует только одно значение кода фирмы, т. е. можно считать, что имеет место полная функциональная зависимость кода фирмы от кода склада. Наименование фирмы определяется однозначно кодом фирмы.

ЗАМЕЧАНИЕ

Если зависимость между КОД_Ф и КОД_СК не выявлена, то все множество реквизитов документа разделится на два не связанных между собой подмножества, а это не логично для реквизитов одного документа.

Все установленные функциональные зависимости реквизитов документа "Справочник складов фирмы" отражены на рис. 2.10.

Заметим, что реквизит КОД_Ф одновременно выступает в роли описательного реквизита в одной связи и ключевого — в другой. Таким образом, здесь мы сталкиваемся с транзитивной зависимостью. Реквизит НАИМ_Ф транзитивно зависит от КОД_СК через КОД_Ф. Тем не менее, специальных действий по расщеплению этой зависимости при следовании приведенным ранее правилам не потребуется.

 

Реквизиты справочника складов	Имя реквизита	Функциональные зависимости
Код фирмы	КОД_Ф
Наименование фирмы	НАИМ_Ф
Код склада	КОД_СК
Наименование склада	НАИМ_СК
Адрес	АДРЕС_СК
Отв. Лицо	ОТВ_ЛИЦО

 

Рис. 2.10. Функциональная зависимость реквизитов справочника складов фирмы

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

Так, при просмотре списка реквизитов сверху находим первый зависимый реквизит КОД_Ф, к которому подходит стрелка, и устанавливаем реквизит (ключевой), от которого идет стрелка — КОД_СК. Далее находим второй зависимый (описательный) реквизит НАИМ_Ф и устанавливаем его ключевой КОД_Ф. Аналогично находим описательный НАИМ_СК и устанавливаем его ключевой КОД_СК и т. д. Выявленное соответствие описательных и ключевых реквизитов представлено в табл. 2.4.

 

Таблица 2.4. Соответствие описательных и ключевых реквизитов документа "Справочник складов фирмы"

Описательные (зависимые) реквизиты	Ключевые реквизиты	ИО, включающий реквизиты
КОД_Ф	КОД_СК	СКЛАД
НАИМ_Ф	КОД_Ф	ФИРМА
НАИМ_СК	КОД_СК	СКЛАД
АДРЕС_СК	КОД_СК	СКЛАД
ОТВ_ЛИЦО	КОД_СК	СКЛАД

 

 

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

Таблица 2.5. Группировка реквизитов по информационным объектам документа "Справочник складов фирмы"

Реквизиты объекта	Признак ключа	Имя информационного объекта	Семантика объекта
КОД_СК	Простой уникальный	СКЛАД	Сведения о складах фирмы
КОД_Ф  НАИМ_СК АДРЕС_СК ОТВ_ЛИЦО
КОД_Ф	Простой уникальный	ФИРМА	Сведения о фирме
НАИМ_Ф

 

Таким образом, на основе анализа документа "Справочник складов фирмы" выделены два информационных объекта: ФИРМА и СКЛАД.

Заметим, что особенность объекта ФИРМА состоит в том, что он имеет единственный экземпляр, поэтому данный объект можно не отображать в базе данных отдельной таблицей.

Выделение объектов плановой и учетной информации

Анализ документа "Договор на поставку товаров ". Определим функциональные зависимости реквизитов документа "Договор", предварительно составив их перечень (рис. 2.11). Присвоим реквизитам сокращенные обозначения — имена.

Реквизиты документа "Договор"	Имя реквизита	Функциональные зависимости
Номер договора	НОМ_ДОГ
Дата договора	ДАТА_ДОГ
Сумма по договору	СУММА_ДОГ
Код покупателя	КОД_ПОК
Код товара	КОД_ТОВ
Срок поставки	СРОК_ПОСТ
Количество поставки товара	КОЛ_ПОСТ
Мин. партия поставки товара	МИН_ПОСТ
Сумма поставки товара	СУММА_ПОСТ

 Рис. 2.11. Функциональные зависимости реквизитов документа "Договор"

Рассмотрим функциональные зависимости между реквизитами общей части документа "Договор". Номер договора присваивается в порядке подготовки нового документа. Этот номер является уникальным среди всех номеров договоров.

Каждый из реквизитов: Дата заключения договора, Идентификатор покупателя (в качестве него примем код, соответствующий ИНН по справочнику покупателей) — имеет единственное значение в договоре. Соответственно, каждый из этих реквизитов однозначно определяется идентификатором документа — Номером договора. Общим идентификатором договора определяется также однозначно реквизит Сумма всего.

Кодом покупателя однозначно определяются описательные реквизиты покупателя: Наименование, ИНН, Адрес, Телефон, Банк, Расчетный счет. В таблице зависимостей их можно не отображать, поскольку информационный объект, образованный этими реквизитами, был уже выделен на основе справочника покупателей.

Описательные реквизиты фирмы, выступающей в данном документе в качестве поставщика, определяются однозначно идентификатором фирмы.

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

ЗАМЕЧАНИЕ

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

 

Описательные реквизиты товара Наименование, Единица измерения, Цена однозначно определены Кодом товара. Эти реквизиты можно не включать в таблицу зависимостей, поскольку их взаимосвязи были установлены ранее, при анализе справочника товаров. Что касается реквизитов-оснований документа, таких как Количество поставки товара, Сумма поставки товара, Мин. партия поставки товара — эти реквизиты внутри документа идентифицируются Кодом товара в соответствующей строке, а полная идентификация среди всех договоров образуется добавлением реквизита Номер договора к реквизиту Код товара. Все это справедливо лишь в том случае, если для любого товара Срок поставки может быть только один. Причем в этом случае реквизиты Количество поставки товара, Сумма поставки товара, Мин. партия поставки товара и Срок поставки товара функционально полно будут зависеть от составного ключа — Номер договора + Код товара.

Допустим, что в договоре для одного товара возможно несколько сроков поставки, тогда срок поставки должен войти в общий идентификатор для реквизитов Количество поставки товара, Сумма поставки товара и Мин. партия поставки товара. Таким образом, эти реквизиты будут функционально полно зависеть от составного ключа Номер договора + Код товара + Срок поставки (см. рис. 2.11).

Выделение информационных объектов по документу "Договор". Проанализировав выявленные функциональные взаимосвязи реквизитов, установим, от каких реквизитов зависит каждый реквизит, к которому подходит стрелка. Таким образом, определим соответствие описательных и ключевых реквизитов. Затем сгруппируем реквизиты, одинаково зависимые от ключевых, и объединим их с ключевыми реквизитами в один информационный объект (ИО). Результат группировки по ИО реквизитов документа "Договор" представлен в табл. 2.6.

 

 

Таблица 2.6. Группировка реквизитов по информационным объектам документа "Договор"

Реквизиты объекта	Признак ключа	Имя информационного объекта	Семантика объекта
НОМ_ДОГ	Простой уникальный	ДОГОВОР	Общие сведения по договору
ДАТА_ДОГ  КОД_ПОК СУММА_ДОГ
НОМ_ДОГ + КОД_ТОВ + СРOK_ПОСТ	Составной уникальный	ПОСТАВКА_ПЛАН	Сведения о поставках товаров по договору
КОЛ_ПОСТ МИН_ПОСТ СУММА_ПОСТ

 

 Анализ документа "Накладная". Рассмотрим функциональные зависимости реквизитов общей части накладной. Номер накладной присваивается в порядке подготовки нового документа. Этот номер можно считать уникальным только среди всех номеров накладных, выписанных на данном складе (т. е. он не повторяется на данном складе). Для уникальной идентификации накладных по всей фирме надо принять составной идентификатор Номер накладной + Код склада.

Реквизиты Дата выписки накладной (отгрузки товаров) и Номер договора имеют единственное значение в накладной и, соответственно, каждый из них однозначно определяется идентификатором накладной (Номер накладной + Код склада). Общим идентификатором накладной определяется также однозначно реквизит Сумма всего. Дата заключения договора однозначно определяется Номером договора, что было уже учтено при анализе договора.

Код покупателя, выбранный ранее его идентификатором, имеет единственное значение в накладной, т. е. он однозначно определяется идентификатором накладной. Однако, как было рассмотрено ранее, Код покупателя однозначно определяется в первичном документе "Договор" Номером договора. То есть здесь имеет место транзитивная зависимость идентификатора покупателя от номера договора через идентификатор накладной. Поэтому будем учитывать функциональную зависимость Кода покупателя только от Номера договора.

ИНН и Наименование покупателя однозначно определяются Кодом покупателя, что уже было учтено при анализе справочника покупателей.

Описательные реквизиты фирмы (ИНН и Наименование фирмы), выступающей в данном документе в качестве поставщика, определяются однозначно идентификатором фирмы — Кодом фирмы. Как было принято ранее, объект ФИРМА не целесообразно отображать отдельным объектом в базе данных.

Описательные реквизиты Наименование склада и Отв. лицо (ФИО ответственного лица) однозначно определены Кодом склада, что уже было учтено при анализе справочника покупателей.

ЗАМЕЧАНИЕ

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

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

ЗАМЕЧАНИЕ

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

Описательные реквизиты товара Наименование, Единица измерения, Цена, Ставка НДС однозначно определены Кодом товара, что уже было учтено при анализе справочника покупателей.

Реквизиты-основания накладной Количество отгруженного товара и Сумма за товар определяют количественные характеристики объекта — отгрузка товаров. Эти реквизиты внутри одной накладной идентифицируются Кодом товара в соответствующей строке, а полная идентификация на всем множестве накладных образуется добавлением к Коду товара идентификатора накладной. Таким образом, реквизиты Количество отгруженного товара и Сумма за товар однозначно определяются составным идентификатором Номер накладной + Код склада + Код товара.

На рис. 2.12 наглядно представлены все рассмотренные функциональные зависимости реквизитов накладной.

Реквизиты документа "Накладная"	Имя реквизита	Функциональные зависимости
Номер накладной	НОМ_НАКЛ
Код склада	КОД_СК
Номер договора	НОМ_ДОГ
Дата отгрузки	ДАТА_ОТГР
Сумма всего	СУММА_НАКЛ
Код товара	КОД_ТОВ
Количество отгруженного товара	КОЛ_ОТГР
Сумма за товар	СУММА_ОТГР

 

Рис. 2.12. Функциональные зависимости реквизитов

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

Таблица 2.7. Группировка реквизитов по информационным объектам документа "Накладная"

Реквизиты ИО	Признак ключа	Имя ИО	Семантика ИО (описание)
НОМ_НАКЛ + КОД_СК	Составной уникальный	НАКЛАДНАЯ	Общие сведения по накладной
ДАТА_ОТГР НОМ_ДОГ СУММА_НАКЛ
НОМ_НАКЛ + КОД_СК + КОД_ТОВ	Составной уникальный	ОТГРУЗКА	Данные по отгрузке товара
КОЛ_ОТГР СУММА_ОТГР

 

 

ЗАМЕЧАНИЕ

Для определения уровня объектов на графе ИЛМ можно, условно удалив объекты нулевого уровня, найти объекты первого уровня. К объектам этого уровня следует отнести объекты, не подчиненные теперь никаким другим объектам. Аналогично определяются объекты каждого следующего уровня. При большом количестве объектов в ИЛМ аналогичные действия выполняются на матрице смежности модели.

Проектирование реляционной базы данных

База данных Access является реляционной базой данных. Такая база данных состоит из взаимосвязанных реляционных таблиц. На этапе проектирования базы данных для выбранной предметной области должна быть определена логическая структура базы данных. Проект логической структуры БД устанавливает состав реляционных таблиц, их структуру и логические связи между таблицами. При формировании структуры каждой таблицы определяется совокупность полей (столбцов), для каждого из которых определяется тип, размер данных и другие свойства. Для таблицы должен быть указан уникальный ключ, который может состоять из одного или нескольких полей. При проектировании базы данных, отвечающей требованиям нормализации, между таблицами определяются логические связи с типом отношений "один-ко-многим" (1: М). Такие связи позволят осуществлять в Access автоматическое поддержание связной целостности и непротиворечивости данных в базе.