- •Тема 1. Введение. Автоматизированные информационно-управляющие системы(аиус). Место автоматизированных банков данных в аиус.
- •Тема 2. Информационные системы. Основные понятия.
- •2.1 Информация и данные.
- •2.1.1. Сигналы и данные.
- •2.1.2. Данные и методы.
- •2.1.3. Понятие об информации.
- •Информация – это продукт взаимодействия данных и адекватных им методов в момент ее образования. Рассмотрим схему данных, метода и информации.
- •2.1.4.Свойства информации.
- •. Инфологический и даталогический аспекты создания информационного обеспечения асу(ио аис-су).
- •2.3 Понятия о бд и системах управления бд (субд).
- •. Автоматический банк данных, как основа подсистемы информационного обеспечения аис.
- •2.4.1. Бд. Уровни представления бд. Логическая и физическая независимость данных.
- •Для обеспечения вышеуказанных свойств предлагались различные архитектуры автоматических банков данных, но наиболее жизнеспособной из них оказалась трехуровневая система организации базы данных.
- •2.4.2. Субд.
- •2.4.3Администраторы бд и другие пользователи. Администратор бд – это лицо или группа лиц, проектирующих и реализующих рациональную организацию банка данных и обеспечивающих его корректную работу.
- •Архитектура банка данных.
- •Классификация ис и бд
- •2.6.2. Ис с архитектурой файл-сервер.
- •Разновидности архитектур информационных систем типа клиент-сервер.
- •1 Клиент – 1 сервер.
- •Модель удаленного доступа к данным.
- •Модель сервера бд.
- •Модель сервера приложений(трехуровневая модель).
- •Корпоративные ис на базе интернет-технологии.
- •Географически распределенные ис(глобальные ис).
- •Географически распределенные ис с использование интернет-технологий.
- •Тема 3. Проектирование Информационных Систем (ио).
- •3.1 Жизненный цикл ис.
- •3.1.1. Планирование разработки.
- •Суть состоит в постановке таких задач, как :
- •3.1.2. Анализ предметной области (по) и определение требований к ис(ио).
- •Проектирование ис. Общими требованиями при проектировании ис являются:
- •Концептуальное проектирование.
- •Этап логического проектирования.
- •Этап физического проектирования
- •Выбор субд.
- •Разработка приложений.
- •Проектирование транзакций.
- •Проектирование пользовательского интерфейса.
- •Реализация.
- •Тестирование.
- •Эксплуатация и сопровождение.
- •3.2.1. Традиционная схема анализа по.
- •Пример схемы информационных потоков при реализации процесса назначения стипендии приведен на рис. 3.2.1.3.
- •3.3. Проектирование концептуальной инфологической модели.
- •При составлении e-r-модели используются 3 основных элемента, с помощью которых отображается по:
- •3.3.2. Создание локальных концептуальных инфалогических моделей(моделирование локальных представлений) - лкимд(лкмд).
- •3.4.1. Логическое проектирование бд.
- •Вводная часть.
- •3.4.2. Подэтап 1. Логическое проектирование бд. Построение и проверка ллмд.
- •Преобразование лкмд в ллмд.
- •Удаление рекурсивных связей.
- •Удаление множественных атрибутов.
- •3.4.2.2. Определение набора отношений исходя из ллмд.
- •3.4.2.2.1. Формирование для связи 1:1 .
- •3.4.2.2.2.Формирование отношений для связей типа 1:m.
- •3.4.2.2.3. Формирование отношений для связей м:м.
- •3.4.2.2.4. Пример формирования отношений исходя из структуры ллмд.
- •3.4.2.2.5. Проверка модели на выполнение транзакций пользователя (фаза4).
- •Определение требований поддержки целостности данных
- •3.4.3. Создание и проверка глмд.
- •3.4.3.1 Слияние ллмд в глмд (фаза 1).
- •3.4.3.2 Проверка глмд (фаза 2).
- •3.4.3.3, Создание окончательного варианта глобальной диаграмы Сущность-Связь (глмд) (фаза 3).
- •Тема 4.Модель данных. Реляционная модель данных.
- •4.1 Модель данных общие понятия
- •4.2. Организация данных в реляционных наборах данных.
- •4.3. Нормализация отношений.
- •4.4. Операции над отношениями в рмд.
- •4.4.1. Операции обработки отношений.
- •2.3. Операция "деление"
- •4.4.2. Операции обновления отношений.
- •Тема 5. Языки запросов для работы с бд реляционного типа.
- •5.1. Краткая характеристика языков.
- •5.2. Описание данных средствами языка sql.
- •5.3. Операторы обработки данных (оод).
- •5.3.1 Операторы (запросы) проекции.
- •5.3.2 Операции селекции.
- •5.3.3 Запросы с использованием специальных функций.
- •5.3.4 Запросы с использованием агрегатных (итоговые) функций.
- •5.3.5 Операторы обновления таблицы в языке sql.
- •5.4. Реализация некоторых операций алгебры средствами реляционного субд foxpro(Visual foxpro).
- •Тема 6. Физические модели баз данных и физическое проектирование
- •6.1 Общие понятия о файловых структурах.
- •6.1.2 Файлы фбд (модель внешней памяти эвм).
- •6.2 Взаимодействия субд, диспетчера файлов и диспетчера дисков и их функции.
- •6.2.1 Схема взаимодействия субд , дф , дд .
- •6.2.2 Диспетчер дисков (базовая система ввода/вывода).
- •6.2.3 Диспетчер файлов.
- •Управление страницами.
- •Управление хранимыми в памяти записями
- •Методы доступа к записям фбд
- •6.3.1. Последовательный доступ(используются для последовательных файлов).
- •6.3.2. Доступ по первичному ключу
- •6.4. Физическое проектирование .
- •6.4.1. Анализ транзакций .
- •6.4.2.Выбор файловой структуры .
- •6.4.2.1. Последовательные файлы .
- •6.4.2.2. Хешированные файлы.
- •6.4.2.3.Индексно-последовательные файлы (isam) .
- •6.4.2.4.Двоичные деревья .
- •6.5. Примеры структур данных в файлах с различной организацией и методов доступа к записям .
- •6.5.2. Последовательные файлы .
- •6.5.3. Хешированные файлы (хф) .
- •6.5.4. Индексные файлы .
- •6.5.4.1. Индексно-последовательные файлы .
- •Тема 7. Методы доступа и защиты данных.
- •7.1 Общие вопросы обеспечения защиты данных в базе.
- •7.2. Методы и приемы защиты данных от несанкционированного доступа, от лиц, пытающихся незаконно получить доступ к бд.
- •7.2.1. Идентификация пользователя.
- •7.2.2. Управление доступом.
- •7.2.3. Шифрование данных (физическая защита).
- •7.3. Обеспечение целостности данных (функция безопасности).
3.4.2.2.3. Формирование отношений для связей м:м.
При наличии связи М:М между двумя сущностями необходимо формировать 3 (три) отношения независимо от КП любой из сущности. Использование 1 (одного) или 2 (двух) отношений в этом случае не избавляет от пустых полей или избыточно дублируемых данных.
Правило 6:
Если степень связи М:М, то независимо от класса принадлежности сущностей формируется 3 (три) отношения. Два отношения соответствуют связываемым сущностям и их ключи являются первичными ключами этих отношений, третье отношение является связным между первыми двумя, а его ключ объединяет ключевые атрибуты связываемых отношений. На Рис 3.4.2.2.20 приведены диаграммы ER-типа(а) и ER-экземпляров(б) и схема отношений сформулированных по правилу 6.
а) ER-типа
б) ER-экземпляров
в) Схема отношений
Рис 3.4.2.2.20. Диаграмма и схема отношений для правила 6
Применим правило 6 к исходным ER-диаграммам. В них степень связи равна М:М, а КП сущности “Преподаватель” и “дисциплина”- не обязательный.
Для наглядности сначала построим одно отношение “Преподаватель” -“дисциплина” (Рис 3.4.2.2.21)
НП |
ФИО |
СТАЖ |
КД |
ЧАСЫ |
Дисциплина |
П1 |
Иванов И.И. |
5 |
К3 |
100 |
ТАУ |
П2 |
Петров П.П. |
7 |
К1 |
60 |
Структура Данных |
П2 |
Петров П.П. |
7 |
К2 |
70 |
Б.Д. |
П3 |
Федоров Ф.Ф |
5 |
К4 |
50 |
Информатика |
П4 |
Семенов С.С. |
10 |
К4 |
50 |
Информатика |
П4 |
Семенов С.С. |
10 |
К5 |
80 |
Программирование |
П5 |
Егоров Е.Е. |
3 |
… |
… |
… |
… |
… |
… |
К6 |
120 |
Физика |
Рис 3.4.2.2.21 Одно отношение, сформированное на основе ER- диаграмм (Рис 3.4.2.2.20) С данным отношением связаны проблемы:
Имеются пустые поля в кортежах, которые содержат следующее:
а) данные о преподавателях, не ведущих дисциплины;
б) данные о дисциплинах, которые не ведутся преподавателями;
2. Избыточное дублирование данных о преподавателях, ведущих более одной дисциплины и избыточное дублирование данных о дисциплинах, которые ведутся несколькими преподавателями (КД).
Применим правило 6 к исходным ER-диаграммам и получим 3 отношения (Рис 3.4.2.2.22).
Преподаватель Ведет Дисциплина
Рис 3.4.2.2.22. Отношения получаемые по правилу 6.
Аналогичные результаты получаются для 3-х других вариантов, различающихся классами принадлежности их сущностей. Рассмотрим применение сформулированных правил на примере проектирования БД методом сущность-связь.
3.4.2.2.4. Пример формирования отношений исходя из структуры ллмд.
Как уже отмечалось было разработана ЛЛМД фрагмента, отображающего отдельный аспект учебной части ВУЗа. Диаграмма ER-типа для такой ЛЛМД представлена на Рис 3.4.2.2.23
Рис 3.4.2.2.23 Диаграмма ER-типа учебной части ВУЗа
Связь “ИМЕЕТ” является связью типа М:1, т.к. одинаковый стаж могут иметь несколько преподавателей. Сущность “Преподаватель” имеет обязательный КП, т.к. каждый преподаватель имеет свой стаж. Сущность “стаж” имеет необязательный КП, т.к. возможны такие значения стажа, которые не имеют ни один из преподавателей.
Связь “ВЕДЕТ” имеет тип М:М, т.к. Пр-ль может вести несколько занятий, а каждое занятие может преподаваться несколькими преподавателями. Занятие, проводимое преподавателями по одной из дисциплин, может быть лекционным, практическим, лабораторным и т.д. Обе сущности в данной связи имеют обязательный КП, в предположении, что нет преподавателей, которые не проводят занятий, и нет занятий, которые не обеспечены преподавателями.
Связь “ЗАНИМАЕТ” имеет тип М:1, так как каждый Пр-ль занимает определенную должность и одинаковые должности могут занимать несколько преподавателей. Сущность “Пр-ль” имеет обязательный КП , т.к. каждый пр-ль занимает должность. Сущность “Должность” имеет необязательный КП, т.к. напротив возможно отсутствие какой-либо должности профессора на кафедре (например, “профессор”).
На основе анализа диаграмм ER-типа (Рис 3.4.2.2.23) с помощью 6-ти сформированных правил получаем набор предварительных отношений, представленных следующими схемами отношений.
Связь “ИМЕЕТ” удовлетворяет условиям правила 4, в соответствии с которым получаем 2 (два) отношения:
ПРЕПОДАВАТЕЛЬ (ФИО, СТАЖ,…)-добавился ключевой атрибут СТАЖ.
СТАЖ (СТАЖ,…)
Связь “ВЕДЕТ” удовлетворяет условиям правила 6, в соответствии с которым получаем 3 (три) отношения:
ПРЕПОДАВАТЕЛЬ (ФИО, СТАЖ,…)
ЗАНЯТИЕ (ГРУППА, ПРЕДМЕТ…)
ВЕДЕТ (ФИО, ГРУППА, ПРЕДМЕТ,…)
Связь “ЗАНИМАЕТ” аналогично связи “ИМЕЕТ” удовлетворяет условиям правила 4, поэтому имеет следующие 2 (два) отношения.
3.1 ПРЕПОДАВАТЕЛЬ (ФИО, СТАЖ, ДОЛЖНОСТЬ,…)
Добавится ключевой атрибут должность.
3.2 ДОЛЖНОСТЬ (ДОЛЖНОСТЬ,…)
После этого рассмотрим необходимость добавления неключевых атрибутов, которые не были выбраны в качестве ключевых ранее, и назначение их одному из предварительных отношений, с тем условием, чтобы отношения отвечали требованиям нормальной формы Бойса-Кодда.
После добавления нескольких атрибутов схемы отношений примут следующий вид:
ПРЕПОДАВАТЕЛЬ (ФИО, СТАЖ, ДОЛЖНОСТЬ, КАФЕДРА…)
СТАЖ (СТАЖ, Д _СТАЖ)
ЗАНЯТИЕ (ГРУППА, ПРЕДМЕТ…)
ВЕДЕТ (ФИО, ГРУППА, ПРЕДМЕТ,ВИД.ЗАНЯТИЯ…)ДОЛЖНОСТЬ (ДОЛЖНОСТЬ, ОКЛАД…)
Схема базы данных для данных отношений представлена на Рис 3.4.2.2.24.
Рис 3.4.2.2.24. Схема базы данных
Замечание:
В рассматриваемом примере отношение “Занятие”, кроме ключевых атрибутов (Группа, Препод.), других атрибутов не имеет. Поэтому оно не несет дополнительной информации, кроме содержащейся в отношении “ВЕДЕТ”. Поэтому отношение “ЗАНЯТИЕ” можно исключить из формируемой схемы базы данных. Если бы имелись другие атрибуты, например атрибут “СЕМЕСТР”, в котором некоторая группа изучает конкретную дисциплину, то получили бы отношение занятие (группа, Предмет, семестр), которое вошло бы в Базу Данных. Ключевые атрибуты (Стаж и должность) из отношений “СТАЖ” и “ДОЛЖНОСТЬ” входят как внешние ключи в отношение “ПРЕПОДАВАТЕЛЬ”. Ключевой атрибут “ФИО” входит как часть составного ключа в отношение “ВЕДЕТ”.
