- •Архитектуры баз данных. Преимущества и недостатки
- •Реляционные базы данных, основные понятия.
- •Понятия и терминология, связанные с таблицей реляционной базы данных
- •1.4.1. Отношение "один-ко-многим"
- •Отношение "один-к-одному"
- •Отношение "многие-ко-многим"
- •Понятия терминология, связанные с полем таблицы
- •Понятия ключевых атрибутов для таблиц и индексов.
- •1.7. Индексы и методы доступа
- •Реляционные отношения и целостность данных. Пример
- •1.4.1. Отношение "один-ко-многим"
- •1.4.2. Отношение "один-к-одному"
- •1.4.3. Отношение "многие-ко-многим"
- •1.4.4. Связь между записями одной таблицы
- •1.5. Ссылочная целостность и каскадные воздействия
- •Навигационный и sql ориентированный подход к обработке данных.
- •Нормализация данных. Первая нормальная форма. Пример
- •Нормализация данных. Третья нормальная форма. Пример
- •Индексы. Определение, назначение, характеристики.
- •Жизненный цикл программного обеспечения. Модели жизненного цикла.
- •Основные этапы программирования (структурный, rad технологии, case технологии). Кризис программирования.
- •Методология системного анализа и системного моделирования. Диаграммы idefo.
- •Язык uml. Назначение.
- •Статические диаграммы uml (варианты использования, классов)
- •Диаграммы поведения uml ( состояний, последовательности, деятельности).
- •Основные принципы организации процесса разработки по по rup.
- •Понятие rup. Основные принципы. Структура процесса проектирования. Инструментальная поддержка.
- •Статическая структура описания rup. Понятия исполнителей и артефактов. Основные технологические процессы.
- •Технологический процесс управления проектом.
- •Технологический процесс процесса моделирования производства. 6 сценариев разработки моделей.
- •Технологический процесс управления требованиями
- •Технологический процесс анализа и проектирования
- •Технологический процесс реализации
- •Технологический процесс тестирования
- •Технологический процесс управления конфигурацией и изменениями
- •Технологический процесс управления средой
- •Технологический процесс распространения
- •Конфигурирование и реализация rup
1.4.3. Отношение "многие-ко-многим"
Отношение "многие-ко-многим" имеет место, когда:
а) записи в родительской таблице может соответствовать больше одной записи в дочерней таблице;
б) записи в дочерней таблице может соответствовать больше одной записи в родительской таблице.
На рис. 1.9 показаны таблицы, состоящие в отношении "многие-к-одному". Каждой учебной группе соответствует несколько преподавателей. Каждый преподаватель может вести, во-первых, несколько разных предметов, и, во-вторых, преподавать в разных группах.
Таблица "Учебные группы и Таблица "Преподаватели" дисциплины"
Группа |
Предмет |
№ преподавателя |
|
№ преподавателя |
ФИО преподавателя |
Кафедра |
ПС-1 |
Программирование |
10 |
-> |
10 |
Красноов Ю.Б. |
ТИ-1 |
ТИ-1 |
Программирование |
12 |
|
12 |
Володин В.Н. |
ТИ-1 |
ПС-1 |
Теория систем |
10 |
|
62 |
Булгаков В.М. |
РИО |
РТ-2 |
Философия |
62 |
|
78 |
Гноенский Л.С. |
ТИ-1 |
ПС-1 |
Социология |
62 |
|
85 |
Подушкин М.А. |
ЭИ-1 |
... |
... |
... |
|
... |
... |
... |
Рис 1.9 Связь "многие-ко-многим"
Многие СУБД не поддерживают связи "многие-ко-многим" на уровне индексов и ссылочной целостности (см. следующий подраздел), хотя и позволяют реализовывать ее в таблицах неявным образом. Аналогично, мнногие CASE-средства (программы для разработки структуры базы данных в виде диаграмм и генерации на их основе физической базы данных) также нe позволяют определять эту связь между таблицами проектируемой базы даннь1Х. Считается, что всякая связь "многие-ко-многим" может быть заменена на одну или более связь "один-ко-многим". Хотя это так, по мнению автора, целесообразность применения такой связи должна рассматриваться прежде всего в контексте разрабатываемой базы данных и приложения для работы с ней, и там, где это удобно, такая связь должна реализовываться.
1.4.4. Связь между записями одной таблицы
Между записями одной таблицы также может существовать связь, то есть одни записи могут ссылаться на другие.
Рассмотрим пример. Пусть необходимо в реляционной БД хранить древовидную структуру произвольного уровня, например, структуру организации (рис. 1.10.) В этом случае минимально достаточно таблицы реляционной БД (рис. 1.11), в которой каждому подразделению организации соответствует одна запись. Эта запись ссылается на запись, соответствующую подразделению более высокого уровня, в которое входит данное подразделение. И только в записи о подразделении самого высокого уровня нет подобной ссылки.
Нужно заметить, что автоматическое обеспечение связен записей внутри одной таблицы реляционными СУБД не поддерживается и эти связи нужно реализовывать программно. Несложно заметить, что удаление записи, на которую имеются ссылки (у нас это записи со значением поля "№ подразделения", кроме 4,5,6,8,9,11), должно блокироваться, поскольку в противном случае в таблице будут иметь место ссылки на несуществующие номера подразделений. Также нельзя изменять номера подразделений, на которые имеются ссылки - это разрушит достоверность данных. Такие действия необходимо реализовывать программно. Рассмотренный пример является частным случаем более общей проблемы - обеспечение ссылочной целостности между таблицами базы данных. Речь об этой проблеме пойдет вследующем разделе.