Базы данных    
Конспект лекций
назад | содержание | вперед

 

Раздел 3. ER-моделирование

В этом разделе обсуждаются следующие темы:

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

 

Тема 3.1. Основы моделирования

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

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

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

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

Хороший проект базы данных — основа хороших приложений. Независимо от уровня мастерства программистов и/или эффективности генератора прикладных программ мы не сможем разработать хорошие приложения без хорошо спроектированной базы данных. А хороший проект базы данных начинается с построения полноценной модели данных.

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

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

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

Различные пользователи и владельцы информации зачастую напоминают известную притчу о "слоне и слепцах": слепцы, которые ощупывали хобот слона, представляли его совершенно другим, чем те, которые ощупывали его ноги или хвост. Все, что нам нужно, — это возможность увидеть слона в целом. Аналогично, дом — это произвольная совокупность комнат; если уж мы собираемся строить дом, то должны, прежде всего, иметь о нем некое общее представление — проект. Точно так же нормальная конфигурация данных требует общего проекта базы данных, основанного на подходящей модели данных.

Если у нас есть хороший проект, то не имеет значения, что представление о данных некоторых прикладных программистов будет отличаться от представления руководителя и/или конечного пользователя. И наоборот, если у нас проекта нет, проблемы, скорее всего, возникнут. Например, программа учета материальных средств или система учета счетов может не вписаться в общие требования к системе, что может потребовать от компании дополнительных затрат в тысячи, а то и миллионы долларов.

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

 

Тема 3.2. Модели данных: уровни абстракции данных

Национальный институт стандартизации США (ANSI) определяет три различных модели данных в соответствии с уровнями абстракции: концептуальную, внешнюю и внутреннюю (рис. 3.1). Но эту классификацию моделей данных необходимо расширить, добавив физическую модель данных, чтобы в этой классификации нашли отражение проблемы реализации специфичные для СУБД во внутренней модели.

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

 

3.2.1 Концептуальная модель

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

Концептуальная модель — основа для идентификации и описания основных объектов данных за исключением подробностей. Наиболее широко используемая концептуальная модель — модель "сущность-связь" (ER-модель). Ранее было показано, что ER-модели иллюстрируются с помощью диаграмм "сущность-связь" (ER-диаграмм, ERD), которые на самом деле являются основой проектирования. ER-диаграммы используются для графического представления концептуальной модели базы данных.

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

Рис. 3.1. Четыре абстрактные модели данных

Используя сущности СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, КУРС, ГРУППА, АУДИТОРИЯ, мы можем описать связи между этими сущностями. Идентифицировав сущности, используем концептуальную модель, графически представленную ER-диаграммой (рис. 3.2), для связывания одной сущности с другой.

На ER-диаграмме можно заметить, что связи описываются глаголами "обучает", "имеются", "создает" и "используется для". То есть преподаватель обучает группу, в группе имеются студенты, а аудитория используется для группы. Обратите внимание, что связи сущностей на рис. 3.2 подразделяются на типы 1:М или M:N. Например, ПРЕПОДАВАТЕЛЬ может обучать несколько групп, но каждая группа обучается только у одного преподавателя, т. е. между преподавателем и группой существует связь 1:М. В группу может входить несколько студентов, и каждый студент может обучаться в нескольких группах, т. е. между ними есть связь M:N. На каждом курсе может быть несколько групп, но каждая группа связана только с одним курсом. Например, может существовать несколько групп (секций) на курсе по базам данных (шифр курса CIS-420). Одна из этих групп может заниматься по понедельникам, средам и пятницам с 8:00 до 8:50, вторая по понедельникам, средам и пятницам с 13:00 до 13:50, третья — по четвергам с 18:00 до 20:40, и все эти три группы имеют шифр курса CIS-420. Наконец, группе необходима одна аудитория, но в данной аудитории в соответствии с расписанием могут заниматься разные группы, т. е. одна группа может заниматься в данной аудитории с 9:00, другая с 11:00 и т. д. Другими словами, между аудиторией и группой есть связь 1:М.

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

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

Рис. 3.2. Концептуальная модель колледжа

Для СУБД имеет значение только название связи — ей нет дела до того, как описывается связь или как она читается. Однако человек предпочитает, чтобы связь была описана на литературном языке. По этой причине описание связи 1:М "читается" от стороны "1" к стороне "М", несмотря на то, как расположены прямоугольники, обозначающие сущности. Следовательно, мы читаем связь между группой и аудиторией на рис. 2 как "в аудитории занимается несколько групп", а связь между преподавателем и группой — как "преподаватель обучает несколько групп".

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

 

3.2.2. Внутренняя модель

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

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

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

Рис. 3.3. Внутренняя модель

В случае, представленном на рис. 3.2, мы реализуем внутреннюю модель, создав базу данных для колледжа с помощью таблиц СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, КУРС, ГРУППА и АУДИТОРИЯ. Мы также создадим промежуточную сущность между ГРУППА и СТУДЕНТ с названием СПИСОК, как это показано на рис. 3.3. Внутренняя модель все еще не зависит от аппаратного обеспечения, поскольку на нее никак не влияет выбор компьютера, на котором установлено данное программное обеспечение. Следовательно, изменение устройства хранения или даже изменение операционной системы не повлияет на требования к разработке внутренней модели.

 

3.2.3. Внешняя модель

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

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

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

Также важно отметить, что хотя представления изолированы друг от друга, они совместно используют общую сущность. Например, программисты Jim и Anne совместно используют сущность ГРУППА. В хорошем проекте такие связи должны учитываться, и программистам должен быть представлен набор ограничений на общие сущности. Внешние модели для колледжа могут выглядеть так, как это показано на рис. 3.4.

 

Рис. 3.4. Внешние модели колледжа

Использование внешних моделей дает следующие важные преимущества:

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

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

 

3.2.4. Физическая модель

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

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

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

 

Тема 3.3. Модель "сущность-связь" (ER-модель)

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

Мы помним, что на основе ER-модели строятся ER-диаграммы. ER-диаграмма представляет собой концептуальное представление базы данных для конечного пользователя. На таких ER-диаграммах отображаются три основные компонента ER-модели: сущности, атрибуты и связи. Поскольку сущность представляет собой объект реального мира, слова "сущность" и "объект" часто обозначают одно и то же.

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

 

3.3.1. Сущности

Ранее мы указывали, что под сущностью на уровне ER-моделирования на самом деле подразумевается набор сущностей, а не единственная сущность. Иначе говоря, слово "сущность" в ER-моделировании соответствует таблице, а не строке в реляционной среде. В ER-модели отдельная строка таблицы называется экземпляром сущности. Как в модели Чена, так и в модели "птичья лапка", сущность изображается прямоугольником, в котором записано имя сущности. Имя сущности — имя существительное — обычно записывается заглавными буквами.

 

3.3.2. Атрибуты

Ранее было показано, что атрибуты описывают свойства сущностей. Например, сущность STUDENT включает в себя атрибуты STU_LNAME (фамилия студента), STU_FNAME (имя студента), STU_INITIAL (инициалы студента). В модели Чена атрибуты изображаются овалами, соединенными линиями с прямоугольником, изображающим сущность. В каждом овале содержится имя того атрибута, который он представляет. В модели "птичья лапка" атрибуты просто записываются в прямоугольнике атрибутов, присоединенном снизу к прямоугольнику сущности (рис. 3.5). Поскольку представление диаграмм с помощью модели Чена требует значительно больше места, некоторые поставщики программного обеспечения, создающего диаграммы Чена, используют стиль изображения атрибутов, принятый в модели "птичья лапка".

Рис. 3.5. Атрибуты сущности СТУДЕНТ: модели Чена и "птичья лапка"

Домены. У атрибутов имеются домены. Домен это набор возможных значений атрибута. Например, домен для числового атрибута средней оценки студента может быть записан в виде интервала [0,4], поскольку минимальное значение атрибута равно 0, а максимальное значение — 4. Домен для символьного атрибут ПОЛ состоит только из двух возможных букв М или Ж или какого-либо другого допустимого обозначения. Домен даты приема на работу в компанию состоит из всех дат, входящих в определенный диапазон (например, от даты создания компании до текущей даты).

Домен может совместно использоваться атрибутами. Например, адреса студентов и адреса преподавателей совместно используют домен всех возможных адресов. На самом деле, словарь данных позволяет новому атрибуту наследовать характеристики существующего атрибута, если для атрибута используется то же самое имя. Например, сущности ПРЕПОДАВАТЕЛЬ и СТУДЕНТ могут каждая иметь атрибут с именем АДРЕС.

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

ИМЯ ТАБЛИЦЫ (КЛЮЧЕВОЙ АТРИБУТ_1, АТРИБУТ 2, АТРИБУТ 3 ... АТРИБУТ К)

Например, сущность АВТОМОБИЛЬ может быть представлена так:

АВТОМОБИЛЬ (АВТ_НОМ, МОД_КОД, АВТ_ГОД, АВТ_ЦВЕТ)

(VIN — это стандартный акроним для идентификационного номера транспортного средства).

С учетом соглашения об именах можно заметить, что атрибут с именем МОД_КОД (код модели), по всей видимости, является внешним ключом, используемым для связывания таблицы автомобилей с какой-то другой таблицей. В этом случае другая таблица, допустим, с именем МОДЕЛЬ, возможно, содержит атрибуты, специфичные для каждой модели (например, МОД_ТИП), в которых хранятся такие описательные элементы, как "двухдверный спортивный купе", "четырехдверный седан" или "кузов-универсал".

В идеальном случае первичный ключ (РК) состоит из единственного атрибута. Например, в таблице на рис. 6 в качестве первичного ключа используется единственный атрибут CLASS_CODE. Однако можно использовать и составной ключ, т. е. первичный ключ, состоящий более чем из одного атрибута. Например, администратор базы данных колледжа может принять решение идентифицировать каждый экземпляр сущности ГРУППА с помощью составного первичного ключа, представляющего собой комбинацию из атрибутов CRS_CODE и CLASS_SECTION, вместо использования одного атрибута CLASS_CODE. При любом подходе каждый экземпляр сущности уникально идентифицируется первичным ключом. В структуре таблицы ГРУППА, представленной на рис. 6, атрибут CLASS_CODE является первичным ключом, а комбинация атрибутов CRS_CODE и CLASS_SECTION представляет собой допустимый потенциальный ключ. Если атрибут CLASS_CODE удалить из сущности ГРУППА, то потенциальный ключ (CRS_CODE и CLASS_SECTION) станет подходящим составным первичным ключом.

Примечание. Напомним, что ранее мы указали на отличие курса (КУРС) от группы (ГРУППА). Группа входит в определенный курс и определяется описанием курса и его секциями. Таким образом, преподаватель, читающий лекции по группам "Базы данных I, Секция 2"; "Базы данных I, Секция 5"; "Базы данных I, Секция 8" и "Таблицы II, Секция 6" читает два курса (Базы данных I и Таблицы II), но ведет занятия в четырех группах! Обычно предлагаемые курсы (КУРС) печатаются в каталоге курсов, в то время как предлагаемые группы (ГРУППА) печатаются каждый раз во время регистрации групп в соответствии с расписанием. Таким образом, у курса есть секции, а потом для секции назначается группа, у которой есть номер.

Рис. 3.6. Содержимое таблицы ГРУППА

Если на рис. 3.6 атрибут CLASS_CODE используется в качестве первичного ключа, то сущность ГРУППА может быть представлена в текстовом виде следующим образом:

ГРУППА(CLASS_CODE, CRS_CODE, CLASS_SECTION, CLASS_TIME, CLASS_ROOM, PROF_NUM)

С другой стороны, если атрибут CLASS_CODE удалить и использовать в качестве первичного ключа комбинацию атрибутов CRS_CODE и CLASS_SECTION, то сущность ГРУППА можно выразить так:

ГРУППА (CRS_CODE, CLASS_SECTION, CLASS_T1ME, CLASS_ROOM, PROF_NUM)

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

Составные и простые атрибуты. Атрибуты подразделяются на простые и составные. Составной атрибут (не путать с составным ключом!) это атрибут, который может быть в дальнейшем разделен на несколько дополнительных атрибутов. Например, атрибут АДРЕС можно разделить на УЛИЦА, ГОРОД, ШТАТ и ПОЧТОВЫЙ_ИНДЕКС. Точно так же атрибут НОМЕР_ТЕЛЕФОНА может быть разделен на КОД_ГОРОДА и Городской Номер_Телефона. Простой атрибут не может быть разделен на атрибуты. Например, ВОЗРАСТ, ПОЛ и СЕМЕЙНОЕ_ПОЛОЖЕНИЕ можно считать простыми атрибутами. Чтобы облегчить детализацию запроса, обычно стоит заменить составные атрибуты на несколько простых.

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

Многозначные атрибуты. Многозначный атрибут это атрибут, который может принимать множество значений. Например, человек может окончить несколько колледжей, семья может иметь несколько телефонных номеров. Точно так же цвет машины можно разделить на цвет крыши, корпуса и отделки. В ER-модели Чена многозначные атрибуты показываются двойной линией, связывающей атрибут и сущность. В модели "птичья лапка" многозначные атрибуты никак не выделяются. ER-диаграмма на рис. 3.7 содержит все представленные нами ранее компоненты. Если внимательно посмотреть на рис. 7, то можно заметить, что атрибут АВТ_НОМ является первичным ключом (РК), a АВТ_ЦВЕТ — это многозначный атрибут сущности АВТОМОБИЛЬ. (Предполагается, что каждый автомобиль идентифицируется уникальным номером АВТ_НОМ).

Рис. 3.7. Многозначный атрибут сущности

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

  • создать внутри данной сущности несколько новых атрибутов, по одному на каждый компонент многозначного атрибута. Например, можно разделить атрибут АВТ_ЦВЕТ сущности АВТОМОБИЛЬ и создать новые атрибуты ЦВЕТ_ВЕРХА, ЦВЕТ_КОРПУСА и ЦВЕТ_ОТДЕЛКИ, как показано на рис. 3.8, и ввести их в сущность АВТОМОБИЛЬ;

Рис. 3.8. Разбиение многозначного атрибута на новые атрибуты

  • создать новую сущность, состоящую из компонентов многозначного атрибута (рис. 3.9). Новую независимую сущность ЦВЕТ затем необходимо связать с исходной сущностью АВТОМОБИЛЬ связью 1:М. Обратите внимание, что такое решение позволяет проектировщику определить цвет для множества различных частей машины (табл. 3.1).

Таблица 3.1. Компоненты многозначного атрибута

Часть кузова

Цвет

верх

белый

корпус

синий

отделка

зеленый

салон

синий

Используя подход, представленный в табл. 3.1, мы получаем дополнительное преимущество: теперь можно назначить цвет любому количеству частей кузова без изменения структуры таблицы. Обратите внимание, что в ER-модели на рис. 3.9 отображены компоненты, перечисленные в табл. 3.1.

Рис. 3.9. Новый набор сущностей, составленный из компонентов многозначного атрибута

Производные атрибуты. Наконец, атрибут может быть производным атрибутом. Производный атрибут это атрибут, который не нужно хранить в базе данных; вместо этого его получают с помощью некоторого алгоритма. Например, возраст служащего СОТР_ВОЗР можно получить как целое значение разности между текущей датой и датой рождения служащего (СОТР_РОЖД). Если вы используете MS Access, то можно записать такое выражение: INT((DATE() - СОТР_РОЖД)/365)

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

Рис. 3.10. Отображение производного атрибута

 

3.3.3. Связи

Связь это ассоциирование сущностей. Сущности, участвующие в связи, называются участниками. В качестве названия связи используется глагол в активной или пассивной форме. Например, “СТУДЕНТ занимается в ГРУППЕ”, "ПРЕПОДАВАТЕЛЬ ведет занятия в ГРУППЕ", "ФАКУЛЬТЕТ нанимает ПРЕПОДАВАТЕЛЯ", "ОТДЕЛОМ руководит СЛУЖАЩИЙ".Связи между сущностями всегда действуют в обоих направлениях, т. е. чтобы установить связь между сущностями КЛИЕНТ и СЧЕТ, необходимо определить, что:

  • клиент может создать несколько счетов;
  • каждый счет создается одним клиентом.

Поскольку мы знаем оба направления связи между КЛИЕНТ и СЧЕТ, легко увидеть, что эту связь нужно отнести к типу 1:М.Связь трудно классифицировать, если известна только одна ее сторона. Например, если вы определите, что:

  • отделом руководит служащий,

то вы не знаете, относится ли эта связь к типу 1:1 или 1:М. Поэтому здесь необходимо задаться вопросом: "Может ли служащий руководить более чем одним отделом?" Если ответ на этот вопрос положительный (да), то это связь 1:М и вторая сторона связи записывается так:

  • СЛУЖАЩИЙ может руководить несколькими ОТДЕЛАМИ.

Если сотрудник не может управлять более чем одним отделом, то это связь 1:1 и вторая часть связи должна быть записана так:

  • СЛУЖАЩИЙ может управлять только одним ОТДЕЛОМ.

 

3.3.4. Связность и мощность связи

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

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

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

Рис. 3.11. Связность и мощность в ER-диаграммах

Например, мощность (1,4) записанная рядом с сущностью ПРЕПОДАВАТЕЛЬ в связи "преподаватель ведет занятия в группе", показывает, что значение внешнего ключа таблицы ПРЕПОДАВАТЕЛЬ встречается, по крайней мере, один раз, но не более четырех раз в таблице ГРУППА. Если бы мощность была записана в виде (1,N), то это означало бы отсутствие ограничения на количество групп, которые ведет преподаватель. Точно так же мощность (1,1), записанная рядом с сущностью ГРУППА, указывает на то, что в каждой группе вести занятия может один и только один преподаватель.

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

 

3.3.5. Сила связей

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

Зависимость существования. Если сущность зависит от существования одной или более других сущностей, то говорят, что она зависима от существования. Например, если сотрудник корпорации XYZ имеет одного или более иждивенцев, то для исчисления налогов можно установить связь "сотрудник имеет иждивенца". В этом случае сущность ИЖДИВЕНЕЦ, очевидно, зависит от наличия сущности СОТРУДНИК, поскольку невозможно существование иждивенца отдельно от сотрудника базы данных компании XYZ.

Если сущность может существовать вне одной или более связанных сущностей, то говорят, что она независима от существования. Например, предположим, что корпорация XYZ использует какие-то детали при выпуске своей продукции. Далее предположим, что некоторые из этих деталей производятся “"у себя”, а другие покупаются у поставщиков. При таком сценарии возможно, что ДЕТАЛЬ существует независимо от ПОСТАВЩИКА в связи "деталь приобретается у поставщика". (Как-никак, по крайней мере некоторыми деталями предприятие будет обеспечено и без поставщика). Поэтому сущность ДЕТАЛЬ не зависит от наличия сущности ПОСТАВЩИК.

Слабые (неидентифицируемые) связи. Если одна сущность независима от существования другой сущности, связь между ними называется слабой связью, также называемой неидентифицируемой связью. С точки зрения проектирования БД слабые связи имеют место, если РК связанной сущности не содержит первичные компоненты порождающей сущности. Предположим, что мы определили сущности КУРС и ГРУППА как

КУРС(CRS_CODE, DEPT_CODE, CRS_DESCRIPTION, CRS_CREDIT)

ГРУППА(CLASS_CODE, CRS_CODE, CLASS_SECTION, CLASS_TIME, ...)

В этом случае между сущностями КУРС и ГРУППА есть слабая связь, поскольку атрибут CLASS_CODE является РК сущности CLASS, в то время как атрибут CRS_CODE сущности CLASS является только FK. В данном случае РК сущности ГРУППА не наследует компонент первичного ключа из сущности КУРС. В модели Чена не делается различий между слабой и сильной связями.

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

КУРС(CRS_CODE, DEPT_CODE, CRS_DESCRIPTION, CRS_CREDIT)

ГРУППА(CRS_CODE, CLASS_SECTION, CLASS_TIME, ... и т. д.)

указывают на то, что между сущностями КУРС и ГРУППА есть сильная связь, поскольку составной РК сущности ГРУППА включает в себя CRS_CODE и CLASS_SECTION. (Обратите внимание, что CRS_CODE в таблице ГРУППА является также FK для сущности КУРС ).

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

Примечание. Необходимо иметь в виду, что порядок, в котором таблицы создаются и загружаются, имеет существенное значение. Например, в связи "на курсе) создаются группы" таблица КУРС должна быть создана до таблицы ГРУППА. В конце концов, неприемлема ситуация, когда внешний ключ таблицы ГРУППА ссылается на еще не существующую таблицу КУРС. В некоторых СУБД проблема последовательности создания таблиц не возникает до тех пор, пока в таблицы не загружаются данные. На самом деле, чтобы избежать нарушения целостности на уровне ссылки, в связи 1:М вы должны, прежде всего, загружать сторону "1", независимо от того, является ли связь сильной или слабой.

 

3.3.6. Участие в связи

Участие сущности в связи может быть либо необязательным, либо обязательным. Участие сущности необязательно, если один экземпляр сущности не требует наличия соответствующего экземпляра сущности в отдельной связи. Например, в связи "на курсе создаются группы", по крайней мере, на некоторых курсах могут и не создаваться группы. Иначе говоря, экземпляр сущности (строка) в таблице КУРС не требует обязательного наличия соответствующего экземпляра сущности в таблице ГРУППА. (Помните, что каждая сущность реализуется в виде таблицы.) Поэтому сущность ГРУППА рассматривается как необязательная по отношению к сущности КУРС. Как в диаграммах Чена, так и в диаграммах "птичья лапка" необязательная связь между сущностями показывается небольшим кружком со стороны необязательной сущности (см. рис. 3.12). Существование необязательности указывает на то, что для необязательной сущности минимальное значение мощности связи равно 0.

Рис. 3.12. Необязательная сущность ГРУППА

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

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

Примечание. Вам может показаться, что связи между необязательными сущностями являются слабыми, а между обязательными — сильными. К сожалению, это суждение не всегда верно. Помните, что участие в связи и сила связи это не одно и то же. Весьма возможно наличие сильной связи между сущностями, когда одна из них является необязательной по отношению к другой. Например, связь между СОТРУДНИК и ИЖДИВЕНЕЦ очевидно сильная, но также очевидно, что ИЖДИВЕНЕЦ для СОТРУДНИК необязателен. И в самом деле, вы не можете требовать от сотрудника, чтобы он имел иждивенцев. Возможно также наличие слабой связи между сущностями, когда одна из них обязательна для другой. Сила связи зависит от того, как формируется РК связанной сущности, в то время как участие в связи зависит от того, как составлены бизнес-правила. Например, бизнес-правила Каждая деталь должна быть получена от поставщика и Деталь может или не может быть получена от поставщика по-разному влияют на необязательность для одних и тех же сущностей! Непонимание этого различия может стать причиной плохого проекта, а также вызвать большие проблемы при вставке и удалении строк в таблицах.

Поскольку участие в связи — столь важный компонент процесса проектирования БД, рассмотрим еще несколько сценариев. Предположим, что колледж принял на работу несколько преподавателей, которые ведут исследования, но не проводят занятия в группах. Если рассмотреть связь "преподаватель обучает группу", то вполне возможен вариант, что преподаватель и не проводит занятия с группой. Следовательно, ГРУППА -необязательная сущность для сущности ПРЕПОДАВАТЕЛЬ. С другой стороны, группа должна заниматься у преподавателя. Следовательно, сущность ПРЕПОДАВАТЕЛЬ обязательна для сущности ГРУППА. Обратите внимание, что в модели Чена на рис. 3.13 рядом с сущностью ПРЕПОДАВАТЕЛЬ показана мощность связи (0,3), указывающая на то, что преподаватель может не вести занятия в группах вообще или же вести занятия не более чем в трех группах. В модели Чена указывается число экземпляров сущности в связанной таблице. Поэтому модель Чена показывает, что в таблице ГРУППА либо вообще не будет связей с сущностью ПРЕПОДАВАТЕЛЬ (0), либо их будет не более трех. И каждая строка таблицы ГРУППА ссылается на одну и только одну строку сущности ПРЕПОДАВАТЕЛЬ — исходя из того, что в каждой группе ведет занятия только один преподаватель.

Рис. 3.13. Необязательная сущность ГРУППА

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

Также очень важно понимать, что семантика задачи может определять тип участия в связи. Например, колледж предлагает несколько курсов; каждый курс имеет несколько групп. Опять-таки, обратите здесь внимание на различие между группой и курсом: в группе ведутся занятия по определенным темам (разделам) данного курса. (Обычно курсы описаны в каталоге университета, в то время как темы занятий в группах описаны в расписании занятий, которое студенты используют при записи в группы.)

Анализируя вклад сущности ГРУППА в связь "на курсе создаются группы", можно заметить, что сущность ГРУППА не может существовать без сущности КУРС. Следовательно, сущность КУРС обязательна в этой связи. Но мы можем предположить два сценария для сущности ГРУППА. Различные сценарии зависят от семантики задачи, т. е. они зависят от того, как определены связи.

  • Сущность ГРУППА необязательна. Возможно, на факультете сначала создается сущность КУРС, а затем после назначения преподавателей создается сущность ГРУППА. В действительности такой сценарий вполне вероятен; могут иметься курсы, для которых разделы (группы) еще не определены. На самом деле, некоторые курсы могут читаться только раз в году и при этом группы создаются не в каждом семестре.
  • Сущность ГРУППА обязательна. Это условие создается посредством ограничения, которое выражается семантической конструкцией вида "на каждом курсе создается одна или более групп". В терминах ER в каждом курсе созданной связи должна иметься, по крайней мере, одна группа. Следовательно, при создании курса (КУРС) всегда должна создаться группа (ГРУППА) для увязки с семантикой задачи.

Помните о практической стороне второго сценария. Учитывая семантику этой связи, в систему не должны включаться курсы, на которых нет, по крайней мере, одного раздела (группы). Желательна ли такая жесткая конфигурация с оперативной точки зрения? Например, когда мы создаем новый курс в базе данных, прежде всего, обновляется таблица КУРС, тем самым вводится сущность КУРС, которая еще не имеет связанной с ней группы (ГРУППА). Естественно, эта проблема снимается, когда сущности ГРУППА будут вставлены в соответствующую таблицу ГРУППА. Однако при такой семантике обязательной связи система будет находиться в состоянии временного несоответствия бизнес-правилам. На практике для большей гибкости проекта желательно определить сущность ГРУППА как необязательную.

Наконец при изучении сценариев нужно помнить о роли СУБД. Для обеспечения целостности данных СУБД должна обеспечивать, чтобы сторона "многие" (ГРУППА) ассоциировалась с таблицей КУРС через правила внешнего ключа. Ответственность за обеспечение целостности данных лежит на стороне "многие", а не на стороне "один". СУБД поддерживает ограничения целостности данных, представленные в бизнес-правилах.

 

3 3.7. Сила связи и слабые сущности

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

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

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

Например, страховой полис компании может страховать служащего и его иждивенцев. В бланке страхового полиса служащий может указать (или не указать) иждивенцев, но иждивенец должен быть связан со служащим. Более того, ИЖДИВЕНЕЦ не может существовать без СОТРУДНИК, т. е. вы не можете получить страховой полис в компании XYZ как иждивенец, если вы не являетесь иждивенцем сотрудника компании! Другими словами, ИЖДИВЕНЕЦ это слабая сущность в связи "у сотрудника есть иждивенцы".

В модели "птичья лапка" слабые сущности изображаются небольшими сегментами в каждом из четырех углов прямоугольника сущности ИЖДИВЕНЕЦ. В модели Чена слабые сущности отображаются с помощью двойной окантовки прямоугольника, который обозначает сущность (рис. 3.14).

Рис. 3.14. Слабая сущность на ER-диаграммах

Слабая сущность наследует все части первичного ключа своего сильного партнера по связи. Например, по крайней мере часть ключа сущности ИЖДИВЕНЕЦ будет наследоваться от сущности СОТРУДНИК:СОТРУДНИК (СОТР_НОМ, СОТР_ФАМ, СОТР_ИМЯ, СОТР_ДРОЖД)ИЖДИВЕНЕЦ (СОТР_НОМ, ИЖД_НОМ, ИЖД_ИМЯ, ИЖД_ДРОЖД)

Обратите внимание, что первичный ключ сущности ИЖДИВЕНЕЦ состоит из двух атрибутов: СОТР_НОМ и ИЖД_НОМ, а СОТР_НОМ наследуется от сущности СОТРУДНИК. Значения атрибута ИЖД_НОМ могут быть, например, 1, 2, 3.

Необходимо помнить, что именно проектировщик БД обычно решает, нужно или нет сущность слабой. Например, при исследовании связи между КУРС и ГРУППА вы можете решить, что сущность ГРУППА должна быть слабой по отношению к сущности КУРС. Кроме того, если вы посмотрите строки сущности ГРУППА, то станет ясно, что ГРУППА не может существовать без КУРС, поэтому здесь налицо зависимость от существования. Например, студент не может записаться на Accounting I, группа АССТ-211, раздел 3 (ГРУППА_КОД 10014), если нет курса АССТ-211. Однако обратите внимание, что первичным ключом таблицы ГРУППА является атрибут ГРУППА_КОД, который не получен из порождающей сущности КУРС, т. е. мы можем представить сущность ГРУППА так: ГРУППА(ГРУППА_КОД, КУРС_КОД, ГРУППА_СЕКЦИЯ, ГРУППА _ВРЕМЯ, АУД_КОД, ПРЕП_НОМ).

Второе требование к слабой сущности не выполняется, поэтому сущность ГРУППА нельзя считать слабой. С другой стороны, если первичный ключ сущности ГРУППА будет определен как составной ключ, состоящий из КУРС_КОД и ГРУППА_СЕКЦИЯ, то мы можем представить сущность ГРУППА так: ГРУППА(КУРС_КОД, ГРУППА_СЕКЦИЯ, ГРУППА _ВРЕМЯ, АУД_КОД, ПРЕП_НОМ)

В этом случае первичный ключ сущности ГРУППА частично произведен от КУРС, поскольку КУРС_КОД является первичным ключом сущности КУРС. При таком положении дел сущность ГРУППА является слабой сущностью по определению. В любом случае, сущность ГРУППА всегда зависима от существования КУРС, невзирая на то, определена она как слабая или нет.

 

3.3.8. Степень связи

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

Рис. 3.15. Три типа связей

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

Примечание. Бинарные связи имеют наибольшее распространение. На самом деле, для упрощения концептуального проектирования большинство связей высокой степени (тернарные и выше) по возможности разбиваются на соответствующие эквиваленты бинарных связей.Хотя большинство связей являются бинарными, использование тернарных (и более высокого порядка) связей дает проектировщику некоторую свободу в отношении семантики задачи. Например, обратите внимание на связи (и их результат!), представленные на рис. 3.16.

Рис. 3.16. Реализация тернарной связи

  • Люди или учреждения, входящие в сущность СПОНСОР жертвуют средства в специальный исследовательский фонд (ФОНД). Исследовательские фонды могут курировать несколько направлений. Например, если фонд создан для поддержки медицинских исследований, то в нем может существовать легочное направление, направление борьбы со СПИДом, направление сердечно-сосудистых заболеваний и т. д.
  • Исследователи, входящие в сущность ПОЛУЧАТЕЛЬ, финансируются из фонда.
  • Все связи здесь можно отнести к типу M:N. Например, спонсоры могут делать вклады в несколько фондов. Фонд может иметь множество спонсоров. Фонд может поддерживать множество исследователей, которые являются получателями средств, а исследователи могут получать помощь от нескольких фондов.
  • Три сущности (СПОНСОР, ПОЛУЧАТЕЛЬ и ФОНД) связаны тернарной связью, которую мы обозначили СПФ. Поскольку тернарную связь невозможно выразить одним глаголом, мы используем акроним СПФ для обозначения связи между сущностями СПОНСОР, ПОЛУЧАТЕЛЬ и ФОНД. Эти связи: “спонсор вкладывает в фонд”, “получатель получает от фонда”, “вложение распределяется в фонды”. Таким образом, сущность СПФ позволяет конечному пользователю БД сопоставить спонсоров фонда с получателями фонда, как показано на рис. 3.16.

При изучении содержимого таблиц на рис. 3.16 обратите внимание, что здесь имеется возможность проследить все транзакции. Например, исследователь П1, специализирующийся на легочных заболеваниях, получил в общей сложности $150 000 ($100 000 от спонсора С1 — Петров и $50000 от спонсора С2 — Волков). Исследователь П2, специализирующийся на сердечно-сосудистых заболеваниях, получил в общей сложности 130000 (30000 от спонсора С1 и $100000 от спонсора С2).

Кроме того, тернарная связь СПФ позволяет нам связать доступные фонды со спонсорами. Например, содержимое таблицы показывает, что спонсор С1 сделал вклад $50 000 на исследования в области сердечно-сосудистых заболеваний, откуда $30 000 были получу исследователем П2, в то время как оставшиеся $20 000 были получены исследователем П3. Заметим, что в модели "птичья лапка" уже показывается, что тернарная связь должна быть реализована как сущность, что упрощает отслеживание транзакций, которые мы только что обсудили.

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

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

Например, унарная связь 1:М может быть представлена как "сотрудник руководит несколькими сотрудниками, а каждый сотрудник подчинен только одному сотруднику". Также, поскольку полигамия незаконна, унарную связь типа 1:1 представляет и следующее высказывание: "сотрудник может состоять в браке с одним и только одним сотрудником". Наконец, унарную связь M:N можно выразить как "курс может предшествовать многим другим курсам, а каждый курс может иметь в качестве предшествующих множество других курсов". Эти связи представлены на рис. 3.17.

Рис. 3.17. ER-представление рекурсивных связей

Связь 1:1, представленная на рис. 3.17, может быть реализована единственной таблицей (рис. 3.18). Обратите внимание: мы можем определить, что Петр Иванов женат на Светлане Ивановой, которая, в свою очередь, замужем за Петром Иваным. A Анна Петрова замужем за Колобовым Антоном, который, в свою очередь, женат на Анне Петровой.

Рис. 3.18. Рекурсивная связь 1:1

Рекурсивная связь 1:М "сотрудник руководит сотрудником", показанная на рис. 3.17, реализована на рис. 3.19.

Рис. 3.19. Реализация рекурсивной связи 1:М

Рекурсивные связи M:N нам более знакомы по колледжу. Например, обратите внимание как связь M:N "курс требует знания курса", представленная на рис. 3.17, реализована на рис. 3.20. В этом примере курс МАТН-243 предваряет курсы QM-261 и QM-362, в то время как QM-362 требует предварительного прохождения курса МАТН-243 и QM-261.

Рис. 3.20. Реализация рекурсивной связи M:N

 

3.3.9. Составные сущности

Вы должны помнить, что реляционная модель требует использования связей 1:М. Если встречается связь типа M:N, то нам придется создать переход между сущностями, соединенными такой связью. Такая переходная промежуточная сущность состоит из первичных ключей каждой из соединяемых сущностей. Пример такого перехода приведен на рис. 3.21. Промежуточную сущность называют также составной сущностью.

Если внимательно посмотреть на таблицы, то можно заметить, что составная сущность СПИСОК зависит от существования двух других сущностей; в ее основе — первичные ключи сущностей, соединяемые с помощью составной сущности. Составная сущность может также содержать дополнительные атрибуты, не играющие существенной роли в связи. Например, хотя в составную сущность должны, включаться первичные ключи сущностей СТУДЕНТ и ГРУППА, в нее также могут входить такие дополнительные атрибуты, как оценки, пропуски занятий и другие данные, уникально идентифицирующие успеваемость студента конкретной группы.

Рис. 3.21.Преобразование связи M:N в две связи 1:M

 

Рис. 3.22. Связь M:N между СТУДЕНТ и ГРУППА

Наконец необходимо помнить, что ключ таблицы СПИСОК (ГРУП_КОД и СТУД_НОМ) целиком составлен из первичных ключей таблиц ГРУППА и СТУДЕНТ.

Реализация небольшой базы данных, представленной на рис. 3.20, требует, чтобы мы четко определили связи. В частности, мы должны знать стороны "1" и "М" каждой связи, а также то, являются ли связи необязательными или обязательными. Например, стоит обратить внимание на следующее:

  • группа может существовать (по крайней мере, в начале регистрации), даже если в ней нет ни одного студента. Поэтому (рис. 3.22) в связи типа M:N между СТУДЕНТ и ГРУППА со стороны сущности СТУДЕНТ нужно использовать символ необязательности.
  • однако поскольку связь между сущностями СТУДЕНТ и ГРУППА разбивается на две связи 1:М при помощи промежуточной сущности СПИСОК, то необязательность переходит в сущность СПИСОК (рис. 23). Иначе говоря, теперь возможна ситуация, когда группа не входит в СПИСОК, если ни один студент в эту группу не записан. Поскольку группа может и не встретиться в СПИСОК, сушность СПИСОК становится необязательной для сущности ГРУППА;
  • Если некто стал студентом, то он должен быть записан, по крайней мере, в одну группу. Говоря кратко, сущность ГРУППА обязательна для сущности СТУДЕНТ. Следовательно, студент должен появиться, по крайней мере один раз в сущности СПИСОК. Естественно, если студент записывается в несколько групп (берет несколько курсов), то он может появиться более одного раза внутри сущности СПИСОК. Например, обратите внимание, что СТУД_НОМ =321542 встречается в таблице СПИСОК три раза (см. рис. 3.21). С другой стороны каждый студент встречается в таблице СТУДЕНТ только один раз. (Например, в таблице СТУДЕНТ на рис. 3.21 СТУД_НОМ =321542 встречается только один раз). Поэтому между СТУДЕНТ и СПИСОК на рис. 3.23 имеет место связь типа 1:М, причем "М" относится к СПИСОК;

Рис. 3.23. Составная сущность на ER-диаграмме

  • из рис. 3.21 следует, что группа может встречаться в таблице СПИСОК более одного раза. Например, ГРУП_КОД = 10014 дважды встречается в таблице СПИСОК. Однако ГРУП_КОД=10014 встречается в таблице ГРУППА только один раз, поэтому между ГРУППА и СПИСОК имеет место связь 1:М. На рис. 3.3 обозначение "М" размещено на стороне СПИСОК, в то время как "1" — на стороне ГРУППА.

 

3.3.10. Супертипы и подтипы сущности

Большинство предприятий принимают на работу людей с различными профессиональными навыками. Например, в университете работают как преподаватели, так и служащие других специальностей. Описывать специализацию всех служащих предприятия в одной таблице очень неудобно. С одной стороны, преподаватели должны отвечать специальным требованиям (например, ученая степень, кафедра и т. д.), которые не нужны для других сотрудников. Поэтому, если сведения обо всех сотрудниках и их квалификации будут описываться единственной таблицей СОТРУДНИК1 и храниться так, как это показано на рис. 3.24, вы или получите много пустых мест в такой таблице, или будете вынуждены вводить большое количество ненужных фиктивных элементов.

Рис. 3.24. Пустые места (null), созданные уникальными атрибутами

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

Рис.3. 25. Иерархия обобщенных представлений

Примечание. Вы можете сказать, что пустые места в таблице Сотрудник на рис. 3.4 можно удалив с помощью флагов, но такое решение трудно осуществимо, когда таблица расширяется путем включения численных значений, связанных с пилотами, например, общий налет в Часах, налет в часах за текущий год и т. д. Если вы используете флаг -999 или 0 (или другой числовой флаг) для "не пилотов", то расчетные значения, такие как общий средний налет, среднегодовой минимальный и максимальный налеты теряют свой смысл. Возможное решение этой проблемы состоит в том, чтобы создать атрибут классификации специальности, а затем выполнить все расчеты с учетом ограничения по этому атрибуту. Такое решение позволит корректно рассчитать численные значения, но также может привести к более сложным форматам запросов, быстрому росту числа атрибутов с классификацией специальности и возможному увеличению квалификационных атрибутов различных типов. В конечном счете проектировщик должен использовать при выборе подхода профессиональное чутье.

Из рис. 3.25 можно видеть, что связи наследуются, т. е. подтип сущности наследует атрибуты и связи от супертипа сущности. Например, все пилоты, механики и бухгалтеры имеют имена, домашние адреса и т. д. Однако ранее было показано сотрудники могут также иметь атрибуты, уникальные для их специализации. Другими словами, супертип набора сущностей обычно связан с несколькими уникальными и непересекающимися подтипами набора Такие непересекающиеся связи обозначаются символом "G".

Супертип и его подтип(ы) поддерживают связь 1:1. Например, иерархия обобщенных представлений позволяет заменить нежелательную структуру таблицы СОТРУДНИК1 (см. рис. 3.24) двумя таблицами, одна из которых представляет супертип СОТРУДНИК, а другая - подтип ПРЕПОДАВАТЕЛЬ (рис. 3.26).

Некоторые супертипы содержат пересекающиеся подтипы. Например, какой-то сотрудник может быть преподавателем и, к тому же, администратором, поскольку руководитель факультета может также вести занятия. Точно так же человек может быть и студентом, и сотрудником, поэтому сущности СТУДЕНТ и СОТРУДНИК являются подтипами сущности СУБЪЕКТ в пересекающейся связи, как сущности ПРЕПОДАВАТЕЛЬ и АДМИНИСТРАТОР являются подтипами сущности СОТРУДНИК в пересекающейся связи. Такие пересекающиеся связи на рис.3.27 обозначены символами "Gs".

В сущности, иерархия обобщенных представлений представляет собой связь "является кем-то". Например, "преподаватель является сотрудником", "администратор является сотрудником" и "сотрудник является субъектом".

Рис. 3.26. Связь СОТРУДНИК/ПРЕПОДАВАТЕЛЬ супертип/подтип

Рис. 3.27. Иерархия обобщенных представлений с пересекающимися подтипами

 

Тема 3.4. Разработка ER-диаграмм

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

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

  • Колледж подразделяется на несколько факультетов: факультет бизнеса, факультет искусства и сцены, факультет обучения и факультет прикладных наук. Каждым факультетом руководит декан. Отметим, что мощность сущности ДЕКАН может быть представлена как (1,1), а сущности ФАКУЛЬТЕТ - тоже как (1,1). (Наименьшее и наибольшее количество деканов факультета равно 1, каждый декан назначается только на один факультет.)

    Существует, конечно, несколько способов оценки связи между сущностями ДЕКАН и ФАКУЛЬТЕТ. Каждый декан является членом группы более высокого уровня, которая называется администрацией, поэтому мы можем включить деканов в сущность АДМИНИСТРАТОР. Однако деканы являются еще и преподавателями и могут вести занятия в группах. Следовательно, деканы могут быть включены в сущность ПРЕПОДАВАТЕЛЬ. Кроме того, администраторы и преподаватели являются сотрудниками. Поэтому в зависимости от требований к информации и представлений проектировщика БД об этих требованиях можно было бы оценить возможность создания связей супертипов/подтипов.Всегда помните, что хороший проект БД требует, чтобы проектировщик учитывал требования к информационному обеспечению и бизнес-правила предприятия. В данной операционной среде колледжа профессиональные качества администрации и преподавателей (ученые степени, звания и т. д.) идентичны и поскольку ни для кого из остальных сотрудников (секретари, смотрители, механики и т. д.) не требуется такая ученая атрибутика, значимые связи супертипов/подтипов сокращены до одной — преподаватель/служащий. Связь суп тип/подтип представлена на уровне реализации с помощью ER-фрагме показанного на рис. 28.

    Поскольку большинство СУБД не поддерживают напрямую связь cyпертип/подтип, проектировщики конвертируют ее в связь 1:1, как показано на диаграмме (см. рис. 3.28), где ПРЕПОДАВАТЕЛЬ является СОТРУДНИКОМ. В данном случае не все сотрудники являются преподавателями, поэтому сущность ПРЕПОДАВАТЕЛЬ необязательна для сущности СОТРУДНИК (другими словами, сотрудник не обязательно должен быть преподавателем). Двойная рамка говорит, что ПРЕПОДАВАТЕЛЬ это слабая сущность. На рис. 28 показано, что сущность ПРЕПОДАВАТЕЛЬ необязательна для сущности СОТРУДНИК - не все являются преподавателями. Также обратите внимание, что сущность ПРЕПОДАВАТЕЛЬ наследует первичный ключ сущности СОТРУДНИК. Поэтому связь между СОТРУДНИК и ПРЕПОДАВАТЕЛЬ является сильной, в то время как сущность ПРЕПОДАВАТЕЛЬ слабая, т.е. она не может существовать без сущности, с которой она связана.

Рис. 3.28. Связь супертип/подтип на ER-диаграмме

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

Принимая во внимание это описание деятельности колледжа, мы можем изобразить фрагмент ER-диаграммы (рис. 3.29).

 

Рис. 3.29. Первый фрагмент ER-диаграммы колледжа

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

  • Каждая кафедра предлагает несколько курсов. Например, кафедра менеджмента и маркетинга предлагает такие курсы, как "Введение в менеджмент", "Принципы маркетинга", "Управление производством" и т. д. Фрагмент ER-диаграммы для этих условий представлен на рис. 3.30. Обратите внимание, что эта связь основа на бизнес-правилах работы колледжа. Если, например, в колледже есть кафедры, которые можно считать "исследовательскими", они могут вообще не предлагать никаких курсов, следовательно, сущность КУРС может быть необязательной для сущности КАФЕДРА.

Рис. 3.30. Второй фрагмент ER-диаграммы колледжа

  • Стоит напомнить, что сущность ГРУППА является частью сущности КУРС. Иначе говоря, кафедра может предлагать несколько разделов (групп) одного курса по базам данных. Каждая из этих групп обучается преподавателем в данный момент и в данном месте, т. е. существует связь 1:М между сущностями КУРС и ГРУППА. Однако поскольку курс может существовать в каталоге курсов колледжа, даже если в нем нет групп, включенных в расписание, сущность ГРУППА необязательна для КУРС. Поэтому связь между КУРС и ГРУППА выглядит так, как это показано на рис. 3.31.

Рис. 3.31. Третий фрагмент ER-диаграммы колледжа

  • На каждой кафедре есть несколько преподавателей. Некоторые из преподавателей руководят кафедрами. Только один из преподавателей может возглавлять кафедру, на которой он работает, и ни один из преподавателей не обязан руководить кафедрой. Следовательно, сущность КАФЕДРА необязательна для сущности ПРЕПОДАВАТЕЛЬ в связи "руководит". Эти связи суммированы в ER-фрагменте, представленном на рис. 3.32.

Рис. 3.32. Четвертый фрагмент ER-диаграммы колледжа

  • Каждый преподаватель может обучать до четырех групп, каждая из которых связана с разделом курса. Преподаватель может заниматься только исследовательской деятельностью и вообще не вести занятия в группах. Фрагмент ER-диаграммы, представленный на рис. 3.33, отображает такое положение дел.

Рис. 3.33. Пятый фрагмент ER-диаграммы колледжа

  • Студент может быть записан в несколько групп, но за данный период обучения он может быть записан в группу только один раз. Например, в течение некоторого периода студент может решить пройти обучение по пяти предметам - "Статистика", "Бухгалтерский учет", "Английский язык", "Базы данных" и "История" — но данный студент не может быть записан в группу по предмету "Статистика" пять раз за период обучения! Каждый студент может записаться не более, чем в 6 классов, а в каждом классе может быть до 35 студентов, таким образом, имеет место связь M:N между сущностями СТУДЕНТ и ГРУППА. Поскольку группа может изначально существовать (в начале периода записи студентов в группы) даже в том случае, если в ней нет (пока) студентов, сущность СТУДЕНТ необязательна для сущности ГРУППА в связи M:N. Эту связь M:N нужно разделить на две связи 1:М с помощью промежуточной сущности СПИСОК, как показано во фрагменте ER-диаграммы на рис. 3.34. Но обратите внимание, что рядом с сущностью СПИСОК поставлен символ необязательности: если есть группа, в которой нет студентов, то эта группа не будет встречаться в таблице СПИСОК. Отметим также, что сущность СПИСОК слабая, она зависит от существования, и в состав ее первичного ключа входят первичные ключи сущностей СТУДЕНТ и ГРУППА.

Рис. 3.34. Шестой фрагмент ER-диаграммы колледжа

  • На каждой кафедре обучается несколько (надеемся, что много!) студентов, которым кафедра предоставляет профилирующие предметы. Однако каждый студент имеет единственный профилирующий предмет и, следовательно, связан с единственной кафедрой (рис. 3.35). Однако в колледже возможно — по крайней мере пока, — чтобы студенты не объявляли свой профилирующий предмет. Такой студент не привязан к конкретной кафедре и поэтому сущность КАФЕДРА необязательна для сущности СТУДЕНТ. Еще раз повторим, что связи между сущностями и сущности сами по себе отражают деятельность организации, т. е. бизнес-правила предприятия определяют компоненты ER-диаграммы!

Рис. 3.35. Седьмой фрагмент ER-диаграммы колледжа

  • У каждого студента есть куратор на кафедре, каждый куратор консультирует несколько студентов. Куратор также является преподавателем, но не все преподаватели курируют студентов. Следовательно, сущность СТУДЕНТ необязательна для сущности ПРЕПОДАВАТЕЛЬ в связи "преподаватель курирует студента " (рис. 3.36).
  • Если внимательно рассмотреть сущность ГРУППА на рис. 3.37, то можно заметить, эта сущность содержит атрибут Ауд_Код (код аудитории). Исходя из соглашения об именах, понятно, что Ауд_Код в ГРУППА является внешним ключом для сущности АУДИТОРИЯ. В свою очередь, каждая аудитория расположена в здании, поэтому мы создадим последний фрагмент диаграммы колледжа, исходя из того, что в здании может быть несколько аудиторий, но каждая аудитория находится в единственном здании (рис. 3.37). На этом фрагменте ER-диаграммы видно, что в некоторых зданиях нет аудиторий. Например, в складских здания может не быть нумерованных аудиторий вообще.

Рис. 3.36. Восьмой фрагмент ER-диаграммы колледжа

Рис. 3.37. Девятый фрагмент ER-диаграммы колледжа

На основе вышеизложенного мы можем определить следующие сущности:

ФАКУЛЬТЕТ

КУРС

КАФЕДРА

ГРУППА

СОТРУДНИК

СПИСОК (промежуточная сущность между СТУДЕНТ и ГРУППА)

ПРЕПОДАВАТЕЛЬ

СТУДЕНТ

ЗДАНИЕ

АУДИТОРИЯ

После того как мы определили значащие сущности, мы можем определить предварительные связи между этими сущностями. Затем необходимо описать атрибуты сущностей. Определение атрибутов сущностей поможет нам лучше понять связи сущностей. Компоненты ER-модели, имена сущностей и их связи представлены в табл. 3.2.

Таблица 3.2. Компоненты ER-модели

Сущность

Связь

Связность

Сущность

ФАКУЛЬТЕТ

имеет в своем составе

1:M

СТУДЕНТ

КАФЕДРА

обучаются

1:M

СТУДЕНТ

КАФЕДРА

нанимает

1:M

ПРЕПОДАВАТЕЛЬ

КАФЕДРА

предлагает

1:M

КУРС

КУРС

подразделяется на

1:M

ГРУППА

ПРЕПОДАВАТЕЛЬ

является

1:1

СОТРУДНИК

ПРЕПОДАВАТЕЛЬ

является деканом

1:1

ФАКУЛЬТЕТ

ПРЕПОДАВАТЕЛЬ

руководит

1:1

КАФЕДРА

ПРЕПОДАВАТЕЛЬ

ведет занятия

1:M

ГРУППА

ПРЕПОДАВАТЕЛЬ

курирует

1:M

СТУДЕНТ

СТУДЕНТ

записан в

M:N

ГРУППА

ЗДАНИЕ

имеется

1:M

АУДИТОРИЯ

АУДИТОРИЯ

используется

1:M

ГРУППА

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

 

Тема 3.5. Противоречивые цели проектирования базы данных

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

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

Рис. 3.38. Полная ER-диаграммы колледжа

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

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

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

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

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

 

Вопросы для самопроверки

1. Какие модели данных вы знаете?
2. Чем концептуальная модель отличается от внешней модели?
3. Что такое домен?
4. Что такое однозначный атрибут?
5. Что такое мощность связи?
6. Чем сильные связи отличаются от слабых связей?
7. Какие степени связи вы знаете?
8. Почему цели проектирования базы данных могут быть противоречивыми?
9. В каких случаях целесообразно использовать супертип сущности?
10. В чем отличие внешней от внутренней модели?

 


назад | содержание | вперед