Иногда в качестве первичного ключа в таблице могут быть выбраны разные столбцы. Выделенный ключ – ключ, явно перечисленный вместе с реляционной схемой. В противном случае говорят о неявном ключе, или возможном ключе, или ключе-кандидате.
12. внешний ключ – это столбец или подмножество столбцов одной таблицы, которые могут служить в качестве первичного ключа для другой таблицы. Внешний ключ таблицы является ссылкой на первичный ключ другой таблицы. Поскольку целью построения БД является хранение всех данных, по возможности, в одном экземпляре, то если некий атрибут присутствует в нескольких отношениях, то его наличие обычно отражает определенную связь между строками этих отношений.
Внешние ключи реализуют связи между таблицами БД.
Внешний ключ, как и первичный ключ, может представлять собой комбинацию столбцов. На практике внешний ключ всегда будет составным, если он ссылается на составной первичный ключ другой таблицы. Количество столбцов и их типы данных в первичном и внешнем ключах должны совпадать.
Если таблица связана с несколькими другими таблицами, она может иметь несколько внешних ключей.
Каждая реляционная таблица обладает следующими свойствами:
- имеет имя, которое отличается от имен всех других таблиц;
- данные в ячейках таблицы должны быть структурно неделимыми. Недопустимо, чтобы в ячейке таблицы содержалось более одной порции информации. Например, номер и серия паспорта должны располагаться в разных столбцах таблицы;
- все столбцы в таблице однородные, т. е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.) и длину;
- каждый столбец имеет уникальное имя;
- одинаковые строки в таблице отсутствуют;
- порядок следования строк и столбцов может быть произвольным, независимо от их переупорядочивания отношение будет оставаться одним и тем же, а потому иметь тот же смысл.
6. Сравнение моделей данных
Достоинство реляционной модели данных заключается в простоте, понятности и удобстве физической реализации на ЭВМ. Именно простота и понятность для пользователя явились основной причиной их широкого использования. Проблемы же эффективности обработки данных этого типа оказались технически вполне разрешимыми.
Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей.
Реляционная модель данных (РМД) отличается от сетевой и иерархической следующими положениями:
1. Независимостью исполнения. Так как в реляционной модели логические и физические представления данных могут различаться, следовательно, при исполнении можно и не знать физических отношений между данными.
2. Логическими ключевыми указателями. РМД использует первичные ключи для представления отношений между двумя записями, так как данная модель отличается независимостью исполнения. Однако, предполагается, что физическая БД (полностью скрытая от пользователя) может использовать адреса указателей и т. д.
3. Высокоуровневыми языками программирования (ЯП). Эти языки манипулируют данными как файлом, а не только одной записью.
Выводы: Таким образом, иерархическая, сетевая и реляционная модели данных различаются в основном способами информационного отображения объектов и их взаимосвязей.
Реляционная и иерархическая модели данных реализуют только линейную структуру таблиц, тогда как сетевая и объектно-ориентированная модели позволяют использовать и нелинейную структуру.
По сути, понятия «исходный» и «порожденный» элемент в иерархических и сетевых моделях, «первичный» и «внешний» ключ в реляционной модели передают одно и то же явление – наличие связи «один – ко – многим» между записями соответствующих файлов.
При использовании иерархической и сетевой моделей от пользователя требуется знание физической организации БД, к которой он должен осуществлять доступ, в то время как при работе с реляционной моделью независимость от данных обеспечивается в значительно большей степени. Следовательно, если в реляционных системах для обработки информации в БД принят декларативный подход (т. е. они указывают, какие данные следует извлечь), то в сетевых и иерархических системах – навигационный подход (т. е. они указывают, как их следует извлечь).
Вопросы для самоконтроля
1. Дайте определение модели данных.
2. Какие основные группы моделей данных Вам известны?
3. Какие структуры данных Вам известны? Какова роль различных структур данных в базах данных?
4. Дате определение линейной и нелинейной структуры данных. Приведите примеры.
5. Расскажите об иерархической модели данных. Приведите пример базы данных с иерархической структурой.
6. Приведите примеры систем баз данных на основе иерархической модели данных.
7. Каковы недостатки иерархической модели данных?
8. Расскажите о сетевой модели данных. Приведите пример базы данных с сетевой структурой.
9. Приведите примеры систем баз данных на основе сетевой модели данных.
10. Каковы недостатки сетевой модели данных?
11. Какая модель данных называется реляционной и почему?
12. Дайте определения основных понятий реляционной модели данных.
13. Дайте определение внешнего ключа. Как его можно указать на схеме?
14. Проведите сравнение моделей данных на основе записей.
Тема 5. Технология проектирования баз данных. Уровни проектирования.
1. Трехуровневая архитектура ANSI/SPARC
Трехуровневая архитектура была впервые предложена в 1975 году Комитетом планирования стандартов и норм SPARC (Standards Planning and Requirements Committee) национального Института Стандартизации США (American National Standard Institute – ANSI). Поэтому модель стала называться ANSI/SPARC.
Цель трехуровневой архитектуры заключается в отделении пользовательского представления БД от ее физического представления. Рассмотрим причины, по которым необходимо выполнить такое разделение:
1. Каждый пользователь должен иметь возможность обращаться к одним и тем же данным, используя свое собственное представление о них. Каждый пользователь должен иметь возможность изменять свое представление о данных, причем это изменение не должно оказывать влияния на других пользователей.
2. Взаимодействие пользователя с БД не должно зависеть от особенностей хранения в ней данных.
3. Администратор БД должен иметь возможность изменять структуру хранения данных в БД, не оказывая влияния на пользовательские представления.
4. Логическая структура БД не должна зависеть от таких изменений физических аспектов хранения информации, как переключение на новое устройство хранения.
5. Администратор БД должен иметь возможность изменять концептуальную или логическую структуру БД без какого-либо влияния на всех пользователей.
Таким образом, в модели ANSI/SPARC отражение предметной области представлено моделями данных трех архитектурных уровней:
- внешнего;
- концептуального;
- внутреннего.
рис. 5.1. Трехуровневая архитектура ANSI-SPARC.
Уровень, на котором воспринимают данные пользователи, называется внешним уровнем (external level). СУБД и ОС воспринимают данные на внутреннем уровне (internal level). Концептуальный уровень представления данных предназначен для отображения внешнего уровня на внутренний и обеспечения необходимой независимости друг от друга.
Внешний уровень описывает ту часть БД, которая относится к каждому пользователю. Внешний уровень состоит из нескольких различных внешних представлений БД. Каждый пользователь имеет дело с представлением реального мира, выраженным в наиболее удобной для него форме. Внешнее представление содержит только те сущности, атрибуты и связи реального мира, которые интересны пользователю. Другие сущности, атрибуты и связи, которые ему неинтересны, также могут быть представлены в БД, но пользователь может даже не подозревать об их существовании.
Помимо этого, различные представления могут по-разному отображать одни и те же данные. (Например, формат даты).
На внешнем уровне имеется несколько внешних схем или подсхем, которые соответствуют разным представлениям данных.
Концептуальный уровень представляет обобщающее представление БД. Этот уровень описывает то, какие данные хранятся в БД, а также связи, существующие между ними.
Концептуальный уровень в трехуровневой архитектуре является промежуточным. Этот уровень содержит логическую структуру всей БД (с точки зрения АБД). Однако этот уровень не содержит никаких сведений о методах хранения данных.
Концептуальная схема является «сердцем» БД. Она поддерживает все внешние представления, а сама поддерживается средствами внутренней схемы. Однако внутренняя схема является всего лишь физическим воплощением концептуальной схемы.
Внутренний уровень содержит физическое представление БД в компьютере. Этот уровень описывает, как информация хранится в БД.
Внутренний уровень описывает физическую реализацию БД и предназначен для достижения оптимальной производительности и обеспечения экономного использования дискового пространства.
Ниже внутреннего уровня находится физический уровень (physical level), который контролируется ОС, но под руководством СУБД.
Трехуровневая архитектура СУБД ANSI-SPARC, включающая внешний, концептуальный и внутренний уровни, позволяет обеспечить независимость хранимых данных от использующих их программ: внешний уровень экранирован от приложений системой управления БД, физический уровень экранирован от СУБД операционной системой (ОС) – в согласии с принципом независимости БД как «сверху» (от прикладных программ), так и «снизу» (от вычислительной аппаратуры).
На рис. 5.2 показано место типов независимости от данных в трехуровневой архитектуре ANSI-SPARC.
Информационные данные любого пользователя в БД должны быть независимы от всех других пользователей. Однако, т. к. информационная модель рассчитана на развитие концептуальной модели, то вносимые в нее изменения не должны оказывать влияния на существующие внешние модели. Это первый уровень независимости данных - логическая независимость.
С другой стороны, внешние модели пользователей никак не связаны с типом физической памяти, в которой будут храниться данные, и с физическими методами доступа к этим данным. Это положение отражает второй уровень независимости данных - физическая независимость.
рис. 5.2. Реализация независимости от данных
в трехуровневой архитектуре ANSI-SPARC.
2. Уровни проектирования БД
В настоящее время при проектировании БД используется трехуровневая архитектура, но в несколько ином виде, чем архитектура ANSI-SPARC. Проектирование содержит три уровня, представленные на рис. 5.3:
· концептуальный;
· логический;
· физический.
Соответствие уровней современного моделирования данных и элементов архитектуры ANSI-SPARC показано на рис. 5.4.
Если в трехуровневой архитектуре ANSI-SPARC локальные концептуальные модели пользователей сливаются в единую концептуальную модель БД, то в современной трехуровневой архитектуре слияние моделей пользователей в единую модель БД происходит на стадии логического проектирования: локальные логические модели БД отдельных пользователей сливаются в глобальную логическую модель БД.
Моделью концептуального уровня является инфологическая модель предметной области. Она представляет собой описание предметной области, выполненное без ориентации на используемые в дальнейшем программные и технические средства. Представление БД на концептуальном уровне обладает свойством уникальности.
Инфологическая модель является человеко - ориентированной моделью, полностью независимой от физических параметров среды, способа хранения данных. В конце концов, этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.
Инфологическая модель представляет интегрированные концептуальные требования всех пользователей к БД данной предметной области.
|
|
рис. 5.4. Соответствие уровней моделирования данных и
элементов архитектуры ANSI-SPARC.
Даталогическая модель является моделью логического уровня и представляет собой отображение логических связей между элементами данных безотносительно к их содержанию и среде хранения. Эта модель строится на языке описания данных (ЯОД), используемом в той конкретной СУБД, в среде которой проектируется БД. Этап создания даталогической модели называется даталогическим проектированием. Описание логической структуры БД на языке СУБД называется схемой.
При проектировании логической структуры БД осуществляется преобразование исходной инфологической модели в модель данных, поддерживаемую конкретной СУБД, и проверка адекватности полученной даталогической модели отображаемой предметной области.
Для любой предметной области существует множество вариантов проектных решений ее отображения в даталогической модели. Методика проектирования должна обеспечивать выбор наиболее подходящего проектного решения.
Даталогическая модель отображает логические связи между информационными данными в данной концептуальной модели. При переходе от инфологической модели к даталогической следует иметь в виду, что инфологическая модель включает в себя всю информацию о предметной области, необходимую и достаточную для проектирования БД. Это не означает, что все сущности, зафиксированные в инфологической модели, должны в явном виде отображаться в даталогической модели. Прежде чем строить даталогическую модель, необходимо еще раз решить, какая информация будет храниться в БД.
На этапе даталогического проектирования используются два направления:
1. фактографический – ориентированный на представление хорошо структурированной информации. (реляционная, иерархическая, сетевая модель данных);
2. документальный – отражающий слабоструктурированную информацию (семантические сети, документальные модели).
В соответствии с этими направлениями проектирования БД также разделяют на фактографические и документальные.
Различным пользователям в информационной модели соответствуют различные подмножества ее логической модели, которые называются внешними моделями пользователей. Таким образом, внешняя модель пользователя представляет собой отображение концептуальных требований этого пользователя в логической модели и соответствует тем представлениям, которые пользователь получает о предметной области на основе логической модели. Следовательно, насколько хорошо спроектирована внешняя модель, настолько полно и точно информационная модель отображает предметную область и настолько полно и точно работает автоматизированная система управления этой предметной областью.
Во время фазы физического моделирования разработчик создает модель, оптимизированную для конкретного приложения и СУБД, т. е. привязывает даталогическую модель к среде хранения. Это та самая модель, которая и реализуется на практике. Она определяет используемые запоминающие устройства, способы физической организации данных в среде хранения. Физическая модель предметной области иначе называется внутренней моделью. Описание физической структуры БД называется схемой хранения.
Даталогическая и физическая модели (рис. 3) являются компьютеро - ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.
Физическая модель БД определяет способ размещения данных на носителях (устройствах внешней памяти), а также способ и средства организации эффективного доступа к ним. Организация хранения данных и доступа к ним в значительной степени зависит от принципов и методов управления данными ОС.
Между логическим и физическим проектированием существует постоянная обратная связь, т. к. решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных.
В современных СУБД разработчику не предоставляется какого-либо выбора на стадии физического моделирования. Способ хранения БД определяется механизмами СУБД автоматически «по умолчанию» на основе спецификаций концептуальной схемы БД.
Ключевым моментом в проектировании БД является разработка механизмов защиты БД в соответствии с требованиями пользователей. Т. о., уже на концептуальном уровне проектирования пользователи, создавая свои представления БД, определяют также свои требования к безопасности данных в будущей БД. Построение локальных даталогических моделей второго уровня проектирования БД и затем объединение их в единую глобальную даталогическую модель БД также предполагает решение вопросов защиты данных. На уровне физического проектирования БД выполняется реализация механизмов защиты данных, разработанная на предыдущих уровнях проектирования: АБД проводит регистрацию пользователей БД, «раздает» им права доступа к данным и полномочия, реализует механизм представлений для конкретной выбранной СУБД и др. Таким образом, решение вопросов защиты данных в БД является очень важной задачей, проходящей «красной нитью» через все уровни и этапы проектирования БД, является звеном, по вертикали связывающим процесс проектирования БД.
Современная трехуровневая модель проектирования БД, включающая концептуальный, логический и физический уровни, так же, как и трехуровневая архитектура ANSI-SPARC, обеспечивает независимость данных. АБД может при необходимости переписать хранимые данные, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы БД без разрушения существующих приложений.
Вопросы для самоконтроля.
1. Расскажите о трехуровневой архитектуре ANSI/SPARC.
2. Какова цель введения трехуровневой архитектуры?
3. Каковы причины введения трехуровневой архитектуры?
4. Дайте определения основных уровней в трехуровневой архитектуре.
5. Какие виды независимости обеспечивает введение трехуровневой архитектуры? Расскажите об этих видах.
6. Почему современная модель трехуровневой архитектуры отличается от модели ANSI/SPARC?
7. Дайте определения инфологической, даталогической и физической моделей проектирования базы данных. Каким уровням проектирования соответствуют эти модели?
8. Какие базы данных являются фактографическими, а какие документальными?
Тема 6. Жизненный цикл баз данных.
БД является фундаментальным компонентом более широкого понятия - информационной системы (ИС). Следовательно, жизненный цикл приложений БД неразрывно связан с жизненным циклом ИС. Этапы жизненного цикла БД показаны на рис. 6.1.
рис. 6.1. Жизненный цикл БД.
Рассмотрим основные действия, выполняемые на каждом этапе жизненного цикла:
- Планирование разработки БД. Этап разработки начинается с маркетинга, т. е. исследования рынка программного обеспечения, поиска аналогов, выяснения потребности в БД.
Планирование разработки БД состоит в определении трех основных компонентов:
- требуемого объема работы;
- необходимых ресурсов;
- общей стоимости проекта.
Для поддержки планирования разработки БД может быть создана корпоративная модель данных, отображающая наиболее важные данные и связи между ними (т. е. сущности и связи предметной области), а также их отношение к различным функциональным сферам предметной области. Обычно корпоративная модель данных имеет вид ER-диаграммы.
Планирование разработки БД также должно включать разработку стандартов, которые определяют, как будет осуществляться сбор данных, каким будет их формат, какая потребуется документация, и как будет выполняться проектирование и реализация приложений.
- Определение требований к системе. Определение диапазона действия и границ приложения БД, состав его пользователей и областей применения.
- Сбор и анализ требований пользователей.
Необходимая для проектирования БД информация может быть собрана следующими способами:
- посредством опроса отдельных пользователей предметной области;
- с помощью наблюдений за деятельностью предметной области;
- посредством изучения документов, которые используются для сбора или представления информации;
- с помощью анкет, предназначенных для сбора информации у широкого круга пользователей;
- за счет использования опыта проектирования других подобных систем.
Сбор и анализ требований является предварительным этапом концептуального проектирования БД, в ходе которого спецификации требований пользователей анализируются с целью выяснения всех необходимых подробностей.
Собранная на этом этапе информация может быть плохо структурирована и включать некоторые неформальные заявления пользователей, которые впоследствии потребуется преобразовать и представить в виде более четко сформулированных требований. Эта цель достигается с помощью методов составления спецификаций требований, к числу которых относятся:
- технология структурного анализа и проектирования (Structured Analysis and Design – SAD);
- диаграммы потоков данных (Data Flow Diagrams – DFD);
- графики «вход – процесс – выход» (Hierarchical Input Process Output – HIPO).
- Проектирование БД. Полный цикл разработки включает концептуальное, логическое и физическое проектирование БД.
Существует два основных подхода к проектированию систем БД: «нисходящий» и «восходящий». При восходящем подходе работа начинается с самого нижнего уровня – уровня определения атрибутов (т. е. свойств сущностей), которые на основе анализа существующих между ними связей группируются в отношения, представляющие типы сущностей и связи между ними. Восходящий подход лучше всего подходит для проектирования простых БД с относительно небольшим количеством атрибутов. Однако использование этого подхода существенно усложняется при проектировании БД с большим количеством атрибутов, установить среди которых все существующие функциональные зависимости довольно затруднительно.
Более подходящей стратегией проектирования сложных БД является использование нисходящего подхода. Начинается этот подход с разработки моделей данных, которые содержат несколько высокоуровневых сущностей и связей, затем работа продолжается в виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним атрибутов. Нисходящий подход демонстрируется в концепции модели «сущность – связь». В этом случае работа начинается с идентификации сущностей и связей между ними, интересующих пользователей в наибольшей степени.
- Выбор целевой СУБД (необязательно). На этом этапе выполняется выбор наиболее подходящей СУБД для приложения БД.
- Разработка приложений. Определение пользовательского интерфейса и прикладных программ, которые используют и обрабатывают БД.
В жизненном цикле системы проектирование БД и приложений выполняется параллельно. В большинстве случаев проектирование приложений нельзя завершить до окончания проектирования БД. С другой стороны, БД предназначена для поддержки приложений, а потому между фазами проектирования БД и проектирования приложений для этой БД должен постоянно происходить обмен информацией.
На этом этапе следует также разработать соответствующий пользовательский интерфейс приложений БД. Этот интерфейс должен предоставлять необходимую пользователю информацию самым удобным для него образом. Пользовательские интерфейсы являются одним из важнейших компонентов системы.
- Реализация. Реализация БД начинается с ее распространения для коммерческих и свободных продуктов или внедрения для собственных разработок и заказных программ. В обоих случаях различают БД, которые не требуют вмешательства специалиста для начала эксплуатации, и БД, нуждающиеся в начальной настройке. Внедрение БД обычно производится с участием разработчиков.
- Конвертирование и загрузка данных. Перенос любых существующих данных в новую БД и модификация любых существующих приложений с целью организации совместной работы с новой БД (выполняется в том случае, если новая БД заменяет старую).
- Тестирование. Приложение БД тестируется с целью обнаружения ошибок, а также его проверки на соответствие всем требованиям, выдвинутым пользователями.
Сбор статистических данных на стадии тестирования позволяет установить показатели надежности и качества созданного программного обеспечения.
Пользователи должны быть вовлечены в процесс тестирования. По завершении тестирования процесс создания прикладной системы считается законченным, и она может быть передана пользователям в промышленную эксплуатацию.
- Эксплуатация и сопровождение. На этом этапе приложение БД считается полностью разработанным и реализованным. Впредь вся система будет находиться под постоянным наблюдением и соответствующим образом поддерживаться. В случае необходимости в функционирующее приложение могут вноситься изменения, отвечающие новым требованиям. Реализация этих изменений проводится посредством повторного выполнения некоторых из перечисленных выше этапов жизненного цикла.
Жизненный цикл БД заканчивается вместе с прекращением ее распространения и сопровождения. Обычно это происходит при моральном устаревании БД.
БД всегда сопровождается документацией, которая содержит следующую информацию:
- характеристика БД (условия предоставления услуг, характер обработки информации, форма собственности, степень доступности, форма представления информации, тип используемой модели данных, характер организации хранения данных, а также предметная область, автор, версия и др.);
- руководство программиста - описание способов настройки БД для решения конкретных задач (в некоторых случаях может отсутствовать);
- руководство пользователя - описание интерфейса пользователя, возможностей БД и процесса ее установки, способов разрешения конфликтных ситуаций.
Обычно документация представляется в бумажной форме или в электронном виде на компакт-диске. Часть документации дублируется во встроенной в программу справочной системе.
Естественно, наиболее значительным фактором в жизненном цикле приложения, работающего с БД, является стадия проектирования. От того, насколько тщательно продумана структура БД, насколько четко определены связи между ее элементами, зависит производительность системы и ее информационная насыщенность, а значит - и время ее жизни.
Вопросы для самоконтроля.
1. Опишите основные этапы жизненного цикла базы данных.
2. Какая информация должна содержаться в документации, сопровождающей базу данных?
3. На каких этапах жизненного цикла разрабатывается документация к базе данных?
Тема 7. Модель предметной области
1. Модель «сущность-связь»
Одним из наиболее популярных средств формализованного представления предметной области систем, ориентированных на обработку фактографической информации, является модель «сущность – связь» - высокоуровневая концептуальная модель данных, которая была разработана Ченом в 1976 году с целью упрощения задачи проектирования БД.
Модель типа "сущность – связь" – это неформальная модель предметной области, которая используется на этапе инфологического проектирования БД и позволяет моделировать объекты предметной области, а также взаимоотношения объектов. Основное ее назначение – семантическое описание предметной области и представление информации для обоснования выбора видов моделей и структур данных, которые в дальнейшем будут использованы в системе.
Построение инфологической модели может выполняться как «вручную», так и с использованием автоматизированных средств проектирования. Модель «сущность – связь» положена в основу значительного количества коммерческих CASE-продуктов, поддерживающих полный цикл разработки систем БД или отдельные его стадии. CASE-средства (Computer - Aided Software / System Engineering) представляют собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем и поддерживаются комплексом взаимосвязанных средств автоматизации.
При построении модели типа "сущность – связь" используются три основных конструктивных элемента: сущность, атрибут и связь. Информация о проекте объединяется с помощью графических ER-диаграмм (Entity Relationship Diagram).
Основу ER-модели составляют следующие предположения:
I. Та часть реального мира - совокупность взаимосвязанных объектов, сведения о которых должны быть помещены в БД, может быть представлена как совокупность сущностей.
Сущность (entity) - любой различимый объект (объект, который мы можем отличить от другого), собирательное понятие, некоторая абстракция реально существующего объекта, информацию о котором необходимо хранить в БД. Сущность может быть объектом с физическим (или реальным) существованием (например, люди, места, самолеты) или объектом с концептуальным (или абстрактным) существованием (например, рейсы, вкус, цвет). Сущность имеет имя, уникальное в пределах модели.
1.1. Разновидности сущностей
1. Сущности подразделяются на сильные и слабые. Сущность является слабой, если ее существование зависит от другой сущности – сильной по отношению к ней. Например, сущность ПОДЧИНЕННЫЙ является слабой по отношению к сущности СОТРУДНИК: если будет удалена запись, соответствующая некоторому сотруднику, имеющему подчиненных, то сведения о подчинении также должны быть удалены.
Слабые сущности называют дочерними (child), зависимыми (dependent) или подчиненными (subordinate), а сильные – родительскими (parent), сущностями-владельцами (owner) или доминантными (dominant).
2. Сущности подразделяются на простые и сложные. Сущность называется простой, если она рассматривается в данном исследовании как неделимая. Сложная сущность представляет собой объединение других сущностей, простых или сложных. Понятие «простая» и «сложная» сущность является относительным. В одном рассмотрении сущность может считаться простой, а в другом эта же сущность может рассматриваться как сложная. Например, сущность АУДИТОРИЯ в случае, если БД строится только для управления учебным процессом, будет рассматриваться как простая. Если же БД будет включать подсистемы для служб энергетика, материально-технического снабжения и др., то АУДИТОРИЯ будет рассматриваться как составная сущность.
Сложные сущности, в сою очередь, разделяются на составные, обобщенные и агрегированные.
i. Составная сущность соответствует отображению отношения «целое – часть». Например, УЗЕЛ – ДЕТАЛИ, КЛАСС - УЧЕНИКИ и т. п.
ii. Обобщенная сущность отражает наличие связи «род – вид». Например, сущности СТУДЕНТ, ШКОЛЬНИК, АСПИРАНТ, УЧАЩИЙСЯ ТЕХНИКУМА образуют обобщенную сущность УЧАЩИЙСЯ. Сущности, составляющие обобщенную сущность, называются ее категориями.
Как «родовая» сущность, так и «видовые» сущности могут обладать определенным набором свойств. Причем наблюдается наследование свойств: «видовая» сущность обладает всеми теми свойствами, которыми обладает «родовая» сущность, плюс свойствами, присущими только сущности этого вида.
iii. Агрегированные сущности соответствуют какому-либо процессу, в который оказываются «вовлеченными» другие сущности. Например, агрегированная сущность ПОСТАВКА объединяет в себе сущности ПОСТАВЩИК, ПОТРЕБИТЕЛЬ, а также саму поставляемую ПРОДУКЦИЮ. Агрегированная сущность также имеет характеризующие ее свойства. В рассматриваемом примере таким свойством может быть РАЗМЕР ПОСТАВКИ.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 |
