Построение Реляционной Структуры На Основе Модели Er

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

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

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

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

Модель ER

• Сущность — реальный или воображаемый объект, информация о котором должна храниться в базе данных.

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

• Связь — связь между двумя (чаще всего) сущностями или между одной и той же сущностью (рекурсивная связь), отображаемая графически на диаграмме.

  Соединение изображается в виде ромба с двумя концами, по одному на каждую сущность.

  Для каждой стороны этой связи установлено:

  1. Степень связи — сколько экземпляров данной сущности связано.

  2. Обязательное подключение — должна ли эта сущность обязательно участвовать в подключении.

Давайте построим диаграмму



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

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

Сущность преобразуется в отношение путем ее изоляции от ER-диаграммы.

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

1. 
   
   

   Концептуальный дизайн

   Строится ER-диаграмма, включающая все сущности и связи.

   Получаем концептуальную (инфологическую) модель.

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

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

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

   Я придумал следующую схему.

   
   
   
   
   Рис.

   2

2. 
   
   

   Логический дизайн

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

   Составляется список атрибутов, затем эти атрибуты распределяются по связям.

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

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

      Первичный ключ этого отношения может быть ключом любого из этих двух объектов.

      В этом случае каждое значение ключа гарантированно появляется один раз в любом экземпляре отношения.

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

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

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

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

   4. Если степень бинарной связи равна 1:M и класс членства связанной с M сущности является обязательным, то достаточно использовать два отношения: по одному для каждой сущности, при условии, что ключ сущности служит первичным ключом для соответствующие отношения.

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

   5. Если степень бинарной связи равна 1:M и класс членства связанной с M сущности не является обязательным, то необходимо использовать три связи: одну для сущности и одну для связи.

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

   6. Если степень бинарной связи — M:M, то для хранения данных необходимы три связи: одна для сущности и одна для связи.

      Ключи сущностей включены в связь.

      Если одна из сущностей вырождена, то связей две (т. е.

      двух таблиц будет достаточно).

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

      Отношение, созданное соединением, содержит среди своих атрибутов ключи сущностей от каждой сущности.

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

   Сущности	Номер правила	Отношение
   Клиент Заказ	4	Клиент(#Клиент Заказ(#Заказ, #Клиент
   Сотрудник Заказ	4	Сотрудник(#Сотрудник Заказ(#Заказ, #Сотрудник
   Заказ Ээлемент заказа	4	Заказ(#Заказ Эorder element(#Эorder element, #Order
   Бригада Ээлемент заказа	4	Бригада(#Бригады Эorder element(#Эelements, #Brigades
   Продукт Ээлемент заказа	4	Продукт(#Продукты Эorder item(#Эitem, #Products
   Клиент Заказ	6	Клиент(#Клиент Заказ(#Заказ Оплата(#Оплата, #Клиент, #Заказ
   Бригада Сотрудник	5	Бригада(#Бригады Сотрудник(#Сотрудник Сотрудник команды(#Сотрудник Бригады, #Сотрудник, #Бригада
   Ээлемент заказа Операция	5	Эзаказать товар(#Эпункт Операция(#Операции Операция записи(#Records, #Эitem, #Operations
   Ээлемент заказа Материал	5	Эзаказать товар(#Эпункт Материал(#Материал Потребление(#Records, #Эelement, #Material

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

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

   Таблица 2

Возможно, кому-то будет интересно.

Что касается «нужно ли это», прислушиваюсь к вашему мнению!



Теги: #проектирование баз данных #реляционная модель #ER-диаграмма #Чулан

• Программа Резервного Копирования Sql Позволяет Вам Выполнять Резервное Копирование И Работать

  19 Oct, 24

• Кот

  19 Oct, 24

• Внедрение Dynamics Gp В Чикаго И Северном Иллинойсе

  19 Oct, 24

• Мурдаль, Гуннар

  19 Oct, 24

• Intel, Mcdonald's, Mentos, Gillette: Как Рождались Самые Узнаваемые Рекламные Джинглы

  19 Oct, 24

• Загрузчик Электронной Почты Google

  19 Oct, 24

• Я Пошел В Офис Arduino; Мы Говорили О Fpga; Нужны Волонтеры

  19 Oct, 24

• Skype: Эксперимент С Телефонной Будкой

  19 Oct, 24

• Завершена Продажа Skype Новым Инвесторам

  19 Oct, 24

• Создание Куба Olap В Ms Sql Server 2012

  19 Oct, 24