Категоризация. Категоризация Моделирование одного подкласса со связью, которая охватывает несколько разных суперклассов

Категоризация Моделирование одного подкласса со связью, которая охватывает несколько разных суперклассов. Каждая связь "суперкласс/подкласс" (включая совместно используемые подклассы) в иерархии специализации/генерализации обладает единственным и отличным от других суперклассом. Линия, соединяющая подкласс-категорию с кружком категоризации, помечается символом принадлежности множеству (с), а в кружок категоризации помещается символ объединения (u).

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

18. Методологія інфологічного проектування БД

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

- Типы сущностей - Домены атрибутов

- Типы связей - Потенциальные ключи

- Атрибуты - Первичные ключи

На первом этапе разработки должны быть выполнены следующие задания:

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

2) Определение важнейших типов связей, существующих между сущностями, выделенными на предыдущем этапе. Установив связи, которые будут иметь место в разрабатываемой модели следует определить кардинальность каждой из них(1:1, 1:N, или M:N). После определения отдельных связей им присваиваются осмысленные имена, которые обязательно будут понятны пользователю. Рекумендуется помещать в словарь данных развернутое описание каждой из связей. Для представления сущностей и связей между ними обычно используются диаграммы сущность-связь (ER)

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

- Имя и описание

- Любые синонимы, имеющиеся для атрибута

- Тип данных и размерность значения

- Значение по умолчанию

- Может ли принимать NULL-значения (обязательный или нет)

- Является ли атрибут составным, и, если так, из каких атрибутов состоит

- Является ли атрибут производным, и какой метод стоит использовать для вычисления

- Является ли множественным

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

5) Определение всех потенциальных ключей, и, если их несколько, выбор среди них первичного ключа. Снова документируем все.

6) Специализация или генерализация типов сущностей (необязательный этап).

7) Создание диаграмм сущность-связь.

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

19. Мета логічного проектування БД. Правила генерування реляційних таблиць для простих зв’язків між сутностями і для зв’язків типу «уточнення/узагальнення»

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

- из каких отношений должна состоять база данных;

- какие атрибуты должны быть у этих отношений;

- какие ограничения должны быть наложены на атрибуты и отношения базы данных, чтобы обеспечить ее целостность.

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

- отношения должны отличаться минимальной избыточностью атрибутов;

- выбранные для отношения первичные ключи должны быть минимальными;

- между атрибутами не должно быть нежелательных функциональных зависимостей;

- выбор отношений и атрибутов должен обеспечивать минимальное дублирование данных;

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

- время выполнения запросов на выборку данных должно удовлетворять предъявляемым требованиям;

- перестройка набора отношений при введении новых типов должна быть минимальной.

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

1. Каждая простая сущность превращается в отношение.

2. Каждый атрибут становится возможным столбцом с тем же именем

3. Компоненты уникального идентификатора сущности превращаются в первичный ключ отношения.

4. Связи M:1 (и 1:1) становятся внешними ключами

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

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

а) все подтипы размещаются в одной таблице;

б) для каждого подтипа строится отдельная таблица.

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

Выделяют три группы правил целостности:

- целостность по сущностям;

- целостность по ссылкам;

- целостность, определяемая пользователем.

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

По способам реализации ограничения целостности делятся на:

- декларативные, выполняемые средствами языка SQL;

- процедурные, выполняемые посредством триггеров и хранимых процедур.

Декларативные ограничения целостности должны обеспечивать:

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

- определение необходимых внешних ключей для обеспечения целостности по ссылкам;

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

- задание неопределенных значений и значений по умолчанию;

- задание условий каскадного удаления и пр.

20. Методологія логічного проектування БД

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