Er модель данных. ER-диаграммы в нотациях Баркера и Мартина. CASE-средства

Основными понятиями метода сущность-связь являются следующие:

Сущность,

Атрибут сущности,

Ключ сущности,

Связь между сущностями,

Степень связи,

Класс принадлежности экземпляров сущности,

Диаграммы ER-экземпляров,

Диаграммы ER-типа.

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

Атрибут представляет собой свойство сущности. Это понятие аналогично понятию атрибута в отношении. Так, атрибутами сущности ПРЕПОДАВАТЕЛЬ может быть его Фамилия, Должность, Стаж (преподавательский) и т. д.

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

Связь двух или более сущностей - предполагает зависимость между атрибутами этих сущностей. Название связи обычно представляется глаголом. Примерами связей между сущностями являются следующие: ПРЕПОДАВАТЕЛЬ ВЕДЕТ ДИСЦИПЛИНУ (Иванов ВЕДЕТ «Базы данных»), ПРЕПОДАВАТЕЛЬ ПРЕПОДАЕТ-В ГРУППЕ (Иванов ПРЕПОДАЕТ-В 256 группе), ПРЕПОДАВАТЕЛЬ РАБОТАЕТ-НА КАФЕДРЕ (Иванов РАБОТАЕТ-НА 25 кафедре).

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

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

диаграммы ER-экземпляров,

диаграммы ER-muna, или ER-диаграммы.

На рис. 1 приведена диаграмма ER-экземпляров для сущностей ПРЕПОДАВАТЕЛЬ и ДИСЦИПЛИНА со связью ВЕДЕТ.

Рисунок 1 - Диаграмма ER-экземпляров

Диаграмма ER-экземпляров показывает, какую конкретно дисциплину (СУБД, ПЛ/1 и т.д.) ведет каждый из преподавателей. На рисунок 2 представлена диаграмма ER-типа, соответствующая рассмотренной диаграмме ER-экземпляров.

Рисунок 2 - Диаграмма ER-типа

На начальном этапе проектирования БД выделяются атрибуты, составляющие ключи сущностей.

На основе анализа диаграмм ER-типа формируются отношения проектируемой БД. При этом учитывается степень связи сущностей и класс их принадлежности, которые, в свою очередь, определяются на основе анализа диаграмм ER-экземпляров соответствующих сущностей.

Степень связи является характеристикой связи между сущностями, которая может быть типа: 1:1, 1:М, М:1, М:М.

Класс принадлежности (КП) сущности может быть: обязательным и необязательным.

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

Варьируя классом принадлежности сущностей для каждого из названных типов связи, можно получить несколько вариантов диаграмм ER-типа. Рассмотрим примеры некоторых из них.

Пример 1. Связи типа 1:1 и необязательный класс принадлежности.

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

Каждый преподаватель ведет не более одной дисциплины, а каждая дисциплина ведется не более чем одним преподавателем (степень связи 1:1);

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

Пример 2. Связи типа 1:1 и обязательный класс принадлежности.

На рис. 3 приведены диаграммы, у которых степень связи между сущностями 1:1, а класс принадлежности обеих сущностей обязательный.

В этом случае каждый преподаватель ведет одну дисциплину и каждая дисциплина ведется одним преподавателем.

Рисунке 3 - Диаграммы для связи 1:1 и обязательным КП обеих сущностей

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

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

При необязательном участии экземпляров сущности в связи дополнительный блок к блоку сущности не пристраивается, а точка размещается на линии связи (рис. 6.2).

Символы на линии связи указывают на степень связи.

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

На практике степень связи и класс принадлежности сущностей при проектировании БД определяется спецификой предметной области. Рассмотрим примеры вариантов со степенью связи 1:М или М:1.

Пример 3. Связи типа 1:М.

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

Пример 4. Связи типа М:1.

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

Примеры с типом связи 1:М или М:1 могут иметь ряд вариантов, отличающихся классом принадлежности одной или обеих сущностей. Обозначим обязательный класс принадлежности символом «О», а необязательный - символом «Н», тогда варианты для связи типа 1:М условно можно представить как: О-О, ОН, Н-О, Н-Н. Для связи типа М:1 также имеются 4 аналогичных варианта.

Пример 5. Связи типа 1:М вариант Н-О.

Каждый преподаватель может вести несколько дисциплин или ни одной, но каждая дисциплина ведется одним преподавателем (рис. 4).

По аналогии легко составить диаграммы и для остальных вариантов.

Пример 6. Связи типа М:М.

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

Как и в случае других типов связей, для связи типа М:М возможны 4 варианта, отличающиеся классом принадлежности сущностей.

Пример 7. Связи типа М:М и вариант класса принадлежности О-Н.

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

Рисунок 4 - Диаграммы для связи типа 1:М варианта Н-О

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

Рисунок 5 - Диаграммы для связи типа М: М и варианта О-Н

ER-модель базы данных

Модель сущность-связь (англ. entity-relationship model, ERM, ER-модель) позволяет описывать концептуальные схемы предметной области.

ER-модель используется при высокоуровневом проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. ER-модель это формальная конструкция, не определяющая графических средств её представления. В качестве стандартного графического представления ER-модели, была разработана диаграмма сущность-связь ER-диаграмма (Entity Relationship Diagram - ER - диаграмма). При проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных.

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

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

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

Степень конца связи указывается графически, множественность связи изображается в виде "вилки" на конце связи. Модальность связи так же изображается графически - необязательность связи помечается кружком на конце связи. Именование связи выражается одним глаголом (рис.13).

Рис.13.

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

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

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

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

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

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

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

Первым шагом при создании логической модели БД является построение ER-диаграммы, состоящей из трех частей: сущностей, атрибутов и взаимосвязей.

Разработано множество инструментов визуального создания ER - диаграмм для различны платформ. В настоящем проекте использовалась разработка MySQL Workbench .

Этот инструмент упрощает проектирование баз данных и обслуживание, автоматизирует, отнимающие много времени и подверженные ошибкам задачи и улучшает связь среди команд разработчиков и архитекторами БД. Он позволяет архитекторам данных визуализировать требования, общаться с заинтересованными лицами по вопросам проектирования прежде, чем будут сделаны инвестиции в проект. Это обеспечивает управляемое моделью проектирование баз данных, которое является самой эффективной методологией для того, чтобы создать реальные и хорошо продуманные базы данных. ER - диаграмма базы данных системы дистанционного тестирования (control_tests ) изображена на рисунке (рис.14). Две вертикальные черточки с одной стороны и "трезубец" с другой обозначают соответственно "связь один ко многим".

Рис. 14. ER - диаграмма базы данных control_test системы дистанционного тестирования

Нормализация базы данных

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

Тем не менее, некоторые каноны, правила все-таки существуют. К таким правилам относятся правила нормализации, т.е. приведения отношений к нормальной форме.

В начале 1980-х гг. были предложены новые подходы к мифологическому проектированию БД, в большей степени ориентированные на БД реляционного типа. Среди работавших в этом направлении исследователей можно назвать Р. Баркера (Richard Barker) и авторов нотации Information Engineering (сокр. IE) Дж. Мартина (James Martin) и К. Финкелыитейна (Clive Finkelstein).

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

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

Рис. 6.2.

а – нотация Баркера; 6 – нотация Мартина (IE)

Нужно отмстить, что из-за особенностей изображения связей нотации Баркера и Мартина в литературе иногда называют "crow"s foot notation" (дословно – "нотация вороньей лапки").

На рис. 6.3 приведен фрагмент диаграммы в нотации Мартина, изображающей две сущности ("Клиент" и "Заказ") и связь между ними. Первичные ключи на рисунке выделяются символом "#". Предполагается, что:

• клиент может разместить один, несколько или ни одного заказа;
• заказ может быть размещен одним и только одним клиентом.

Рис. 6.3.

В настоящее время также широкое распространение получила нотация, определенная стандартом IDEF1X (полное название на англ. – Integration Definition for Information Modeling), речь о которой пойдет в следующем параграфе.

Задача проектирования БД для современной информационной системы корпоративного уровня может быть достаточно трудоемкой и требовать совместной работы большой группы специалистов – аналитиков, разработчиков БД, разработчиков прикладного ПО, специалистов в предметной области, для которой разрабатывается БД. Для автоматизации этого процесса широко используются CASE-средства – программные средства, поддерживающие одну или несколько технологий проектирования БД (также есть средства проектирования ПО и т.д.). В качестве примера можно назвать программные продукты ERwin Data Modeler (разработчик – компания СА Technologies), ER/Studio (разработчик – Embarcadero Technologies), PowerDesigner (разработчик – компания Sybase, в настоящее время приобретенная SAP). Отчасти подобная функциональность реализована и в популярном офисном программном продукте Microsoft Visio.

ERwin и подобные ему CASE-средства позволяют решать как задачи прямого проектирования (англ. forward-engineering), т.е. получения структуры БД на основе построенной ER-диаграммы, так и обратного проектирования (англ. reverse-engineering), когда ER-диаграмма создается на основе анализа структуры существующей БД.

Далее рассмотрена методология проектирования и нотация (правила изображения) диаграмм IDEF1X, а приводимые примеры будут иллюстрироваться с использованием программного продукта ERwin Data Modeler v. 9 в версии Community Edition. Данная версия продукта свободно распространяется, ее можно получить через веб-сайт erwin.com. Наиболее существенным ограничением версии ERwin Community Edition является небольшое количество объектов в модели – не более 25, но для учебных целей это не является критичным. Для разработки БД со сложной структурой рекомендуется использовать другие версии продукта.

Наряду с нотацией IDEF1X, ERwin поддерживает нотацию 1Е, особенности современной версии которой описаны далее.

[править]

Материал из Википедии - свободной энциклопедии

У этого термина существуют и другие значения, см. ER .

Модель сущность-связь (ER-модель) (англ. entity-relationship model , ERM) - модель данных, позволяющая описыватьконцептуальные схемы предметной области.

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

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (англ. entity-relationship diagram , ERD).

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

Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен Ченом (англ. Peter Pin-Shen Chen ) , американским профессором компьютерных наук в университете штата Луизиана .

На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных. Среди множества разновидностей ER-моделей одна из наиболее развитых применяется в системе CASE фирмы ORACLE. Ее мы и рассмотрим. Более точно, мы сосредоточимся на структурной части этой модели.

Основными понятиями ER-модели являются сущность, связь и атрибут.

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

Ниже изображена сущность АЭРОПОРТ с примерными объектами Шереметьево и Хитроу:

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

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

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

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

В изображенном ниже примере связь между сущностями БИЛЕТ и ПАССАЖИР связывает билеты и пассажиров. При том конец сущности с именем "для" позволяет связывать с одним пассажиром более одного билета, причем каждый билет должен быть связан с каким-либо пассажиром. Конец сущности с именем "имеет" означает, что каждый билет может принадлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет.

Лаконичной устной трактовкой изображенной диаграммы является следующая:

Каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА;

Каждый ПАССАЖИР может иметь один или более БИЛЕТОВ.

Каждый ЧЕЛОВЕК является сыном одного и только одного ЧЕЛОВЕКА;

Каждый ЧЕЛОВЕК может являться отцом для одного или более ЛЮДЕЙ ("ЧЕЛОВЕКОВ").

К статьям Разработка → Отношения таблиц базы данных и Разработка → Проектирование баз данных хабравчанина ueasley хотелось бы сделать небольшое дополнение.

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

Правила эти применяются к ER-модели, то есть модели «сущность-связь».

ER-модель

ER -модель представляет собой схему, составными элементами которой являются:

• Сущность - это реальный, либо воображаемый объект, информацию о котором необходимо хранить в базе данных. На диаграмме ER-модели сущность изображается в виде прямоугольника, содержащего имя сущности.
• Связь - отображаемая графически на диаграмме ассоциация между двумя (чаще всего) сущностями, или между одной и той же сущностью (рекурсивная связь). Связь изображается ромбом, на котором выделяются два конца, по одному на каждую сущность. Для каждой стороны этой связи устанавливаются:
  1. Степень связи - сколько экземпляров данной сущности связывается
  2. Обязательность связи - обязательно ли данная сущность должна участвовать в связи.

Приведу пример:
Пусть необходимо хранить информацию о клиентах и их заказах. Построим диаграмму

Заметим, что со стороны сущности «ЗАКАЗ» связь обозначена дополнительным прямоугольником - это обозначение того, что каждому экземпляру сущности «ЗАКАЗ» соответствует экземпляр сущности «КЛИЕНТ» (для клиента же наличие заказа не обязательно). Степень «M» означает, что для каждого экземпляра сущности «КЛИЕНТ» могут существовать несколько экземпляров сущности «ЗАКАЗ» (но не наоборот, поскольку для каждого заказа всегда только один заказчик - ставим степень «1»)

Отношение (обычно оно соответствует таблице в базе данных) не следует путать с сущностью. Сущность переходит в отношение путем выделения её из ER-диаграммы.

Этапы проектирования

1. Концептуальное проектирование

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

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

   У меня получилась следующая диаграмма.

   
   Рис. 2

2. Логическое проектирование

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

   Переход к реляционной структуре (построение набора отношений) производится по следующим правилам:

   1. Если степень бинарной связи равна 1:1 и класс принадлежности обеих сущностей обязательный, то требуется только одно отношение. Первичным ключом этого отношения может быть ключ любой из этих двух сущностей. В этом случае гарантируется однократное появление каждого значения ключа в любом экземпляре отношения.
   2. Если степень бинарной связи равна 1:1 и класс одной из сущностей необязательный, то необходимо построение двух отношений, под каждую сущность необходимо выделение одного отношения. Ключ сущности, для которого класс принадлежности является необязательным, добавляется в качестве атрибута в отношение, выделенное для сущности с обязательным классом принадлежности.
   3. Если степень бинарной связи равна 1:1 и класс принадлежности ни одной из сущностей не является необязательным, то используется три отношения - по одному для каждой сущности - ключи которых служат в качестве первичных в соответствующих отношениях и одного для связи. Отношение, выделенное для связи, будет иметь по одному ключу сущности от каждой сущности.
   4. Если степень бинарной связи равна 1: М и класс принадлежности М-связной сущности обязательный, то достаточно использовать два отношения: по одному на каждую сущность, при условии, что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Ключ же односвязной сущности должен быть добавлен как атрибут в отношение, отводимое М-связной сущности.
   5. Если степень бинарной связи равна 1: М и класс принадлежности М-связной сущности необязателен, то необходимо использовать три отношения: по одному на сущность и одно для связи. Связь должна иметь среди своих атрибутов ключ сущности от каждой сущности.
   6. Если степень бинарной связи равна М: М, то для хранения данных необходимо три отношения: по одному на сущность и одно для связи. Ключи сущности входят в связь. Если одна из сущностей вырождена, то - два отношения (т.е. достаточно будет двух таблиц).
   7. В случае трехсторонней связи необходимо использовать четыре отношения: по одному на сущность и одно для связи. Отношение, порождаемое связью, имеет в себе среди атрибутов ключи сущности от каждой сущности.

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

   Сущности	Номер правила	Отношения
   Клиент Заказ	4	Клиент(#Клиента Заказ(#Заказа, #Клиента
   Сотрудник Заказ	4	Сотрудник(#Сотрудника Заказ(#Заказа, #Сотрудника
   Заказ Элемент заказа	4	Заказ(#Заказа Элемент заказа(#Элемента заказа, #Заказа
   Бригада Элемент заказа	4	Бригада(#Бригады Элемент заказа(#Элемента, #Бригады
   Изделие Элемент заказа	4	Изделие(#Изделия Элемент заказа(#Элемента, #Изделия
   Клиент Заказ	6	Клиент(#Клиента Заказ(#Заказа Платеж(#Платежа, #Клиента, #Заказа
   Бригада Сотрудник	5	Бригада(#Бригады Сотрудник(#Сотрудника Сотрудник бригады(#Сотрудника бригады, #Сотрудника, #Бригады
   Элемент заказа Операция	5	Элемент заказа(#Элемента Операция(#Операции Запись операции(#Записи, #Элемента, #Операции
   Элемент заказа Материал	5	Элемент заказа(#Элемента Материал(#Материала Расход(#Записи, #Элемента, #Материала

   Табл. 1

   Распределив атрибуты по полученным отношениям, получим (в списке полей на первом месте - первичный ключ, остальные, помеченные «#», являются внешними ключами):

   БРИГАДА	(#Бригады, #Бригадира, Расположение)
   ДОЛЖНОСТЬ	(#Должности, Должность, Оклад)
   ЗАКАЗ	(#Заказа, #Клиента, #Сотрудника, ДатаРазмещения, ТребуемаяДата, ДатаИсполнения, Описание)
   КЛИЕНТ	(#Клиента, Название, Имя, Фамилия, ОрганизацияИлиОтдел, Адрес, НомерТелефона, АдресЭлектроннойПочты)
   ЗАПИСЬОПЕРАЦИИ	(#Записи, #Элемента,#Операции, #Сотрудника, Количество)
   ОПЛАТА	(#Оплаты, #Клиента, #Заказа, СуммаОплаты, ДатаОплаты, Заметки)
   РАСХОД	(#Записи, #РасхМат, #Елемента, Количество)
   СОСТАВ	(#Элемента, #Заказа, #Товара, #Бригады, Количество)
   СОТРБРИГАДЫ	(#СотрБригады, #Бригады,#Сотрудника)
   СОТРУДНИК	(#Сотрудника, НомерПаспорта, Фамилия, Имя, Отчество, #Должности, Адрес, ДомашнийТелефон, РабочийТелефон, ДатаРождения, ДатаНайма, ДатаОкончДоговора, Фотография, Заметки)
   ОПЕРАЦИЯ	(#Операции, Описание, Стоимость, Время, Оборудование, Выполнение)
   МАТЕРИАЛ	(#РасхМат, НаимРасхМат, Цена, Плотность, Тип, Состав)
   ТОВАР	(#Товара, Марка, Название, ОписаниеТовара, Тип, СерийныйНомер, НаСкладе, Цена)

   Табл. 2

Вот так нас учили делать в университете. Может будет кому-нибудь интересно. Насчет «нужно ли это», слушаю ваши мнения!