Помимо  «основных» таблиц, «изначально» присутствующих в БД, приведённые операции позволяют получать выводимые таблицы –«представления», получаемые в результате применения операций.

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

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

      Основы  реляционной модели данных были впервые изложены в статье Е. Кодда в 1970 г., в которой он опубликовал свои 12 правил соответствия произвольной СУБД реляционной модели, дополнив основные понятия реляционных баз данных определениями, важными для практики. Ниже приводятся эти правила вместе с дополняющим их подразумеваемым общим положением.

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

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

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

      3. Правило наличия значения. В полностью реляционной СУБД должны иметься специальные индикаторы (отличные от пустой символьной строки или строки из одних пробелов и отличные от нуля или какого-то другого числового значения) для выражения (на логическом уровне, систематично и независимо от типа данных) того факта, что значение отсутствует по меньшей мере по двум различным причинам: его действительно нет либо оно неприменимо к данной позиции. СУБД должна не только отражать этот факт, но и распространять на такие индикаторы свои функции манипулирования данными независимо от типа данных.

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

      5. Правило полноты языка работы  с данными. Сколько бы много в СУБД ни поддерживалось языков и режимов работы с данными, должен иметься по крайней мере один язык, выразимый в виде командных строк в некотором удобном синтаксисе, который бы позволял формулировать:

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

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

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

      8. Правило физической независимости. Диалоговые операторы и прикладные программы на логическом уровне не должны страдать от каких-либо изменений во внутреннем хранении данных или в методах доступа СУБД.

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

      10. Правило сохранения целостности. Диалоговые операторы и прикладные программы не должны изменяться при изменении правил целостности в БД (задаваемых языком работы с данными и хранимых в системном каталоге).

      11. Правило независимости от распределённости. Диалоговые операторы и прикладные программы на логическом уровне не должны страдать от совершаемого физического разнесения данных (если первоначально СУБД работала с нераспределёнными данными) или перераспределения (если СУБД действительно распределённая).

      12. Правило ненарушения реляционного  языка. Если в реляционной СУБД имеется язык низкого уровня (для работы с отдельными строками), он не должен позволять нарушать или «обходить» правила, сформулированные на языке высокого уровня (множественном) и занесённые в системный каталог.

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

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

      В настоящее время СУБД именно реляционного типа имеют наибольшее применение. 

 

2. ПОСТАНОВКА  ЗАДАЧИ 

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

      База  данных создается для поддержки  следующих процессов:

• учёт комплектов ПК;
• учёт поставок комплектов и комплектующих;
• ведение справочников поставщиков и комплектующих.

      Необходимо  создать таблицы:

• Поставщик (ИНН, Наименование, Адрес);
• Справочник комплектующих (Номенклатурный номер, Наименование);
• Комплектующие (Номенклатурный номер, ИНН поставщика, Наличие, Цена);
• Комплект (Номер комплекта, Наименование, ИНН поставщика, Количество, Цена);
• Состав комплекта (Номер комплекта, Номенклатурный номер).

      Отчёты, запросы которые необходимо реализовать:

• сведения об указанном комплекте (состав комплекта, количество комплектов);
• сведения о наличии указанного комплектующего изделия;
• сведения об имеющихся изделиях указанного поставщика.

 

3. Анализ предметной области

 

3.1. ОБЩЕЕ ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ 

      Наименование  предприятия/отдела: отдел автоматизации компании «Профавтоматизация», занимающейся комплексной автоматизацией учёта и деятельности предприятий с использованием систем «1С:Предприятие», Papyrus, «Компас» и т.п.

      Предметная  область: комплектация персональных компьютеров.

      Цель  разработки информационной системы: учёт поступивших комплектов ПК и комплектующих, ведение справочников поставщиков и комплектующих, оперативное получение данных о поставщиках и имеющихся изделиях, получение отчётов об имеющихся комплектующих в разрезе поставщиков и о наличии и составе комплектов ПК, что позволит повысить эффективность принятия решений по аппаратному обеспечению новых проектов.

      Точка зрения: ИТ-менеджер отдела автоматизации.

      Пользователи: ИТ-менеджер отдела автоматизации, главный инженер компании. 

3.2. БИЗНЕС-ПРОЦЕССЫ 

      База  данных проектируется для поддержки следующих бизнес-процессов:

1. Учёт состава комплектов ПК и их количества.
2. Учёт поставленных комплектующих и комплектов ПК.
3. Учёт поставщиков изделий.

 

3.3 ОПИСАНИЕ ВХОДНОЙ И ВЫХОДНОЙ ДОКУМЕНТАЦИИ 

      Входной документацией служит:

• Накладная на приход товара.

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

      Выходной  информацией служит:

• отчёты о наличии комплектующих, по поставщикам и по наименованию;
• отчёт о составе комплекта и его наличии.

 

3.4. БИЗНЕС-ПРАВИЛА 

      Описание  бизнес-правил выполнения бизнес-процессов  для данной предметной области:

1. Одно и тоже комплектующее изделие, комплект ПК может быть поставлено разными поставщиками.
2. Каждое комплектующее изделие имеет свой номенклатурный номер, комплект ПК – номер комплекта.
3. В одной поставке могут быть как комплектующие, так и комплекты ПК.

 

3.5. ИНФОРМАЦИОННЫЕ ПОТРЕБНОСТИ ПОЛЬЗОВАТЕЛЕЙ 

      Разрабатываемая система предназначена для реализации следующих информационных потребностей:

• отчёт об указанном комплекте (состав комплекта, количество комплектов);
• отчёт о наличии указанного комплектующего изделия;
• отчёт об имеющихся изделиях указанного поставщика.

 

 

4. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ БАЗЫ ДАННЫХ 

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

• Поставщик;
• Справочник комплектующих;
• Комплектующие;
• Комплект;
• Состав комплекта;
• Приходная накладная.

      Свойства  атрибутов представлены в таблице 4.1.

Таблица 4.1

Свойства  атрибутов