Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
КИТ ШПОРЫ-1.docx
Скачиваний:
2
Добавлен:
01.03.2025
Размер:
226 Кб
Скачать
☆

3.25 Класс принад-ти сущ-ти, его представл-е на er-диаг

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

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

На рис. 1.4 изображены возможные ER-диаграммы для связи М:N c учетом класса принадлежности сущности.

На ER-диаграмме 1 КП обеих сущностей необязател.

На ER-диаграмме 2 КП сущ-ти КЛИЕНТ обязательн, а сущности СЧЕТ необязательный.

На ER-диаграмме 3 КП сущ-ти КЛИЕНТ необязательн, а сущности СЧЕТ обязательный.

На ER-диаграмме 4 КП обеих сущностей обязательн.

3.26 Правила преобраз-я  ER-диагр в реляц Т в случ связ 1:1.

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

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

Правило 3 Если связь типа 1:1 и класс принадл-ти обеих сущ-ей яв-ся необязател, то необход построить 3 таблиц – по одной для каждой сущ-ти и 1 для связи. Первич ключ сущ-ти д б первич ключом соответ-ей табл. Таблица для связи среди св атрибутов должн им ключи обеих сущ-тей.

3.27 Пп er-диаграмм в реляц т в случае связи 1:м, м:n.

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

Правило 5 Если связь типа 1:М и класс принад-ти сущ-ти на стороне М яв-ся необязател, то необход построить 3 табл – по одной для каждой сущ-ти и 1 для связи. Первич ключ сущ-ти д б первич ключом соотв-щей табл. Табл для связи среди св атрибутов должн им ключи обеих сущ-тей.

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

3.28 Нормализация таблиц, ее цель. Первая нормал форма. Вторая нормал форма. Третья нормал форма.

Реляционная БД считается эффективной, если она обладает приведенными ниже характеристиками.

1. Минимизация избыточности данных. В БД присутствует избыточность, если одни и те же данные находятся в нескольких местах. Вследствие этого память компа исп-ся неэкономно и времени на корректировку данных тратится больше. Так в табл. 1.1 содержится много избыточной информации.

2. Минимальное использование отсутствующих значений (Null-значений). В нашем примере неясно, означают ли Null-значения атрибута "Преподаватель", что для группы А2 не определен преподаватель или его Ф.И.О. не введено. Из-за неопределенности интерпретации Null-значений их исп-е желательно свести к минимуму.

3. Предотвращение потери информации. Если, например, студент Шкляр Е.К. решит не изучать немецкий язык, то придется удалить запись со сведениями о нем и тогда вообще будет потеряна И о данном курсе.

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

Табл находится в 1НФ, если все ее поля содержат только простые неделимые значения.

Табл находится в 2НФ, если она удовл требованиям 1НФ и неключевые поля функ-но полно зависят от первичного ключа.

Табл находится в 3НФ, если она удовл требованиям 2НФ и не содерж транзитивных зависимостей. Транзитивн зав-ть – зав-ть, при котор какое-либо неключ поле завис от др неключ поля, а то в свою очередь зависит от ключа.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]