- •Особенности структурного анализа и проектирования информационных систем
- •Введение
- •1. Построение моделей бизнес-процессов по стандарту idef0
- •1.1. Примитивы стандарта idef0
- •1.2. Виды ресурсов стандарта idef0 и их взаимосвязь
- •1.3. Особенности построения моделей по стандарту idef0
- •1.4. Пример декомпозиции процесса
- •1.5. Пример построения диаграмм idef0
- •1.6. Работа с тоннелями
- •1.7. Особенности создания диаграмм в программах bpWin и Ramus
- •1.8. Именование объектов в bpWin
- •1.9. Решение проблем с кодировкой и автоматической проверкой
- •1.10. Варианты заданий по построению моделей бизнес-процессов
- •1.11. Контрольные вопросы
- •1.12. Варианты тестовых заданий по контролю знаний в сфере построения моделей бизнес-процессов
- •2. Построение диаграмм потоков данных
- •2.1. Общие особенности методологии dfd
- •2.2. Внешние сущности
- •2.3. Системы и подсистемы
- •2.4. Процессы
- •2.5. Накопители данных
- •2.6. Потоки данных
- •2.7. Построение иерархии диаграмм потоков данных
- •2.8. Пример построения диаграммы потоков данных в программе bpwin
- •2.9. Особенности построения диаграмм dfd в программе Ramus
- •2.9.1. Создание новой диаграммы, работа с примитивами, классификаторами, особенности декомпозиции
- •2.9.2. Подробный пример построения диаграммы dfd
- •2.10. Варианты заданий по построению диаграмм потоков данных
- •2.11. Контрольные вопросы
- •2.12. Варианты тестовых заданий по контролю знаний в сфере построения диаграмм потоков данных
- •3. Проектирование реляционных баз данных посредством стандарта idef1x
- •3.1. Особенности построения структуры баз данных
- •3.2. Виды связей между таблицами
- •3.3. Особенности стандарта idef1x
- •3.4. Особенности построения схем idef1x в программе ErWin
- •3.4.1. Общие особенности программы ErWin
- •3.4.2. Работа с панелью инструментов и сущностями
- •3.4.3. Работа со связями между таблицами
- •3.5. Особенности построения схем idef1x в программе dbDesigner
- •3.5.1. Особенности работы с программой
- •3.5.2. Необходимые для работы кнопки панели инструментов
- •3.5.3. Настройка внешнего вида схем под стандарт idef1x
- •3.5.4. Работа с таблицами
- •3.5.5. Связи между таблицами
- •3.5.6. Удаление объектов схемы
- •3.5.7. Пример схемы idef1x в dbDesigner
- •3.6. Варианты заданий по построению схем реляционных баз данных
- •3.6. Контрольные вопросы
- •3.7. Варианты тестовых заданий по контролю знаний в сфере построения схем баз данных
- •4. Проектирование диалога с пользователем посредством транзитивных сетей
- •4.1. Проектирование диалога с пользователем
- •4.2. Простая транзитивная сеть
- •4.3. Рекурсивная транзитивная сеть
- •4.4. Подсеть, не связанная с рекурсией
- •4.5. Проектирование конкурентного диалога
- •4.6. Особенности построения транзитивных сетей в программе Dia
- •4.6.1. Подготовка новой панели под создание транзитивных сетей
- •4.6.2. Основные моменты построения транзитивных сетей в программе Dia
- •4.6.3. Пример построения транзитивной сети в программе Dia
- •4.7. Варианты заданий по построению логики диалога с пользователем
- •4.8. Контрольные вопросы
- •4.9. Варианты тестовых заданий по контролю знаний в сфере построения логики диалога пользователя с системой
- •Литература
- •Особенности структурного анализа и проектирования информационных систем
3.2. Виды связей между таблицами
Между таблицами БД существуют связи. Рассмотрим два основных вида связей между таблицами БД: «один-ко-многим» и «многие-ко-многим».
Связь «один-ко-многим» в реляционных БД позволяет описать иерархию сущностей предметной области. Рассмотрим особенности связи на примере. Из предметной области «Университет» возьмем сущности «Студент» и «Группа». Между ними прослеживается конкретная связь: студент обычно учится в одной конкретной группе, в свою очередь, в группе учится много студентов (Конечно же, существуют исключения, но мы рассмотрим абстрактный пример, и не будем их касаться). Фактически это означает, что одной записи из таблицы «Группа» может соответствовать несколько записей таблицы «Студент».
Содержимое таблицы «Группа» разместим в таблице 3.2.
Таблица 3.2
Пример таблицы «Группа»
Номер группы |
Название |
1 |
41-ЭИ |
2 |
41-ИТ |
3 |
51-АП |
Схематически связь записей таблиц «Студент» и «Группа» можно выразить следующим образом.
Рис. 3.1. Схематическое изображение связи «один-ко-многим»
Из таблиц 3.1 и 3.2 видно, что в группе 41-ИТ учатся два студента. Каждый студент при этом учится в одной конкретной группе. Таблица «Группа», одной записи которой может соответствовать несколько записей таблицы «Студент», находится выше по иерархии, чем таблица «Студент». Если существует две связанные по принципу «один-ко-многим» таблицы, то та, что стоит выше по иерархии (одной записи которой может соответствовать несколько из связанной таблицы), называется родительской, а та, что ниже, - дочерней. Таблица «Группа» в данном случае родительская, а «Студент» - дочерняя.
В БД связь «один-ко-многим» выражается следующим образом. В дочернюю таблицу добавляется внешний ключ – набор полей, содержащих значения записей первичного ключа родительской таблицы. Значения внешнего ключа, конечно же, не будут уникальными, так как одной записи родительской таблицы могут соответствовать несколько записей дочерней.
Вернемся к нашему примеру. Изменим структуру таблицы Студент, учитывая специфику внешнего ключа. Исключим из таблицы Студент информацию о группе, оставив для связи только внешний ключ (таблица 3.3).
Таблица 3.3
Пример таблицы «Студент»
Номер зачетки |
Имя |
Фамилия |
Возраст |
Номер группы |
567238 |
Иван |
Иванов |
21 |
2 |
652664 |
Петр |
Петров |
22 |
3 |
564343 |
Андрей |
Сидоров |
21 |
2 |
Будем работать с таблицами 3.2 и 3.3. В таблице Студент поле «Номер группы» является внешним ключом родительской таблицы «Группа». Пусть студент Иванов учится в группе 41-ИТ. В таблице «Группа» экземпляру с названием «41-ИТ» соответствует первичный ключ со значением «2». Поэтому значение внешнего ключа для студента Иванова устанавливается равным 2. Теперь по значению внешнего ключа можно, используя связь определить всю информацию о группе, в которой учится студент. Студент Петров учится в группе 51-АП. В таблице «Группа» экземпляру с названием «51-АП» соответствует первичный ключ со значением «3». Поэтому значение внешнего ключа для студента Петрова устанавливается равным 3.
Связь «один-ко-многим» бывает идентифицирующей и неидентифицирующей. Если связь идентифицирующая, то внешний ключ будет входить в состав первичного ключа дочерней таблицы. Если связь неидентифицирующая, то внешний ключ не будет входить в состав первичного ключа дочерней таблицы. Вид связи определяется из предметной области. Если первичного ключа дочерней таблицы достаточно, чтобы однозначно идентифицировать записи дочерней таблицы, то используется неидентифицирующая связь. Если же однозначно идентифицировать записи дочерней таблицы будет способен лишь первичный ключ дочерней таблицы в совокупности с внешним ключом, то используется идентифицирующая связь.
Необходимо по возможности использовать неидентифицирующие связи «один-ко-многим» для поддержания требования минимальности первичных ключей.
Связь «многие-ко-многим» между двумя таблицами возникает, если конкретной записи из первой таблице может соответствовать несколько записей из второй, и конкретной записи из второй таблицы может соответствовать несколько записей из первой. Рассмотрим пример.
Выделим в предметной области «Университет» две сущности: «Студент» и «Предмет». Между ними прослеживается связь: студент изучает много предметов, а один и тот же предмет может изучаться многими студентами.
Общий вид таблицы «Предмет» представлен в таблице 3.4.
Таблица 3.4
Пример таблицы Предмет
Номер предмета |
Название |
1 |
Математика |
2 |
КСЕ |
3 |
Экономическая теория |
Пусть схематически связь записей таблиц «Студент» и «Предмет» можно выразить следующим образом.
Рис. 3.2. Схематическое изображение связи «многие-ко-многим»
В данном случае математику изучают три студента, КСЕ – два. Студенты Петров и Сидоров изучают по два предмета. Отразим эту связь в виде таблиц БД.
Связь «многие-ко-многим» обычно выражается созданием новой таблицы и добавлением двух идентифицирующих связей «один-ко-многим» таким образом, чтобы новая таблица была одновременно дочерней для обеих таблиц, связываемых по принципу «многие-ко-многим».
Для выражения связи «многие-ко-многим» между таблицами Студент и Предмет создадим еще одну таблицу «Изучает предмет». Ее структура представлена в таблице 3.5.
Таблица 3.5
Пример таблицы «Изучает предмет»
Номер зачетки |
Номер предмета |
567238 |
1 |
652664 |
1 |
652664 |
2 |
564343 |
1 |
564343 |
2 |
Таблица, созданная для выражения связи «многие-ко-многим», может иметь собственные поля, если этого требует предметная область, но в данном случае таблица «Изучает предмет» необходима только для связи таблиц Студент и предмет и не имеет собственных полей. Поле «Номер зачетки» является внешним ключом таблицы Студент, а поле «Номер предмета» является внешним ключом таблицы Предмет. Оба поля входят в первичный ключ, так как связи «один-ко-многим», где родительскими таблицами выступают Студент и Предмет, являются идентифицирующими. В таблице 3.5 реализованы все связи рисунка 3.2.
Используем таблицы 3.3, 3.4 и 3.5. Иванов Иван изучает математику. Записи таблицы Студент с фамилией и именем Иванов Иван соответствует значение первичного ключа 567238, а записи таблицы Предмет с названием Математика соответствует значение первичного ключа 1. Эти два значения связаны между собой и образуют первую запись таблицы «Изучает предмет». По этой записи можно без труда определить всю информацию о студенте и предмете, который он изучает, через первичные ключи таблиц. Петров Петр изучает КСЕ. Записи таблицы Студент с фамилией и именем Петров Петр соответствует значение первичного ключа 652664, а записи таблицы Предмет с названием КСЕ соответствует значение первичного ключа 2. Эти два значения связаны между собой и образуют третью запись таблицы «Изучает предмет».
