
- •Общие сведения Сведения об эумк
- •Методические рекомендации по изучению дисциплины
- •Рабочая учебная программа
- •Учреждение образования
- •«Белорусский государственный университет
- •Информатики и радиоэлектроники»
- •Пояснительная записка
- •Содержание дисциплины
- •1. Название тем лекционных занятий, их содержание, объем в часах.
- •2 Перечень тем ипр их наименование и объем в часах
- •3 Перечень тем контрольных работ их наименование и объем в часах
- •4. Курсовая работа, ее характеристика
- •Перечень тем курсовых работ
- •5. Литература
- •5.1 Основная
- •5.2 Дополнительная
- •6. Перечень компьютерных программ, наглядных и других пособий, методических указаний и материалов и технических средств обучения
- •7. Учебно-методическая карта дисциплины
- •1.1.3. Способы организации знаний в базах знаний
- •1.1.4. Применение баз знаний
- •1.1.5. Виды моделей баз данных
- •2. Теория баз данных
- •2.1. История развития представлений о базах данных
- •2.1.1. Области применения вычислительной техники
- •2.1.2. Базы данных и информационные системы
- •2.1.3. История развития баз данных
- •2.1.4. Этапы развития баз данных
- •2.2. Основные термины и определения теории бд, виды бд и их отличия
- •2.2.1. Классификация бд
- •2.3. Реляционные бд, понятие сущности и связи
- •2.3.1. Общие определения
- •2.3.2. Факты о реляционной модели данных
- •2.3.3. Достоинства реляционной модели данных
- •2.3.4. Недостатки реляционной модели данных
- •2.3.5. Целостность бд
- •2.3.6. Отношения
- •2.3.7. Кортежи и отношения
- •2.3.8. Связи
- •2.3.9. Ключи отношений
- •2.3.10. Ссылочная целостность
- •2.3.11. Консистентность данных
- •2.4. Многоуровневая архитектура баз данных, понятие физического и логического уровней баз данных
- •2.4.1. Определения
- •2.4.2. Многоуровневая структура баз данных
- •Indexed р#
- •2.4.3. Постоянная и переменная длина записи
- •2.4.4. Способы представления данных
- •2.4.5. Простейший вариант – плоский файл
- •2.4.6. Факторизация по значениям поля
- •2.4.7. Индексирование по полям
- •2.4.8. Комбинация простых представлений
- •2.4.9. Использование цепочек указателей
- •2.4.10. Многосписочные структуры
- •2.4.11. Инвертированная организация
- •2.4.12. Иерархическая организация
- •2.4.14. Промежуточный итог
- •2.4.15. Методы индексирования
- •2.4.16. Индексирование по комбинации полей
- •2.4.17. Селективный индекс
- •2.4.18. Индексация по методу сжатия
- •2.4.19. Фронтальное сжатие
- •2.4.20. Сжатие окончания
- •2.4.21. Символьные указатели
- •2.4.23. Индексно-последовательная организация
- •2.4.24. Сбалансированные деревья
- •2.4.25. Ведение файла
- •2.4.26. Хэширование
- •2.5.2. Факторы эффективности хэширования
- •2.5.3. Размер участка памяти
- •2.5.4. Плотность заполнения
- •2.5.5. Алгоритмы хэширования
- •2.5.6. Размещение записей в области переполнения
- •2.5.7. Итог
- •2.6. Механизмы обработки и хранения данных в бд
- •2.6.1. Введение
- •2.6.2. Механизмы обработки и хранения данных в ms-sql 6.0-6.5
- •2.6.3. Механизмы обработки и хранения данных в ms-sql 7.0 и более поздних версиях
- •2.6.4. Метод доступа isam
- •2.6.5. Метод доспута MyIsam
- •2.6.6. Метод доступа vsam
- •2.6.7. Включение записей в *sam-файлы
- •2.6.8. Размещение индексов для *sam-файлов
- •2.6.9. Метод доступа InnoDb
- •InnoDb в MySql 5.1
- •2.7.3. Сетевые структуры
- •3.1.4. Стандарты разработки бд/субд
- •3.1.5. Sql и его стандарты
- •3.1.6. Использование методологии idef1x
- •3.1.7. Пример логической и физической схемы в ErWin
- •3.1.8. Минимальный набор стандартных таблиц
- •3.1.8. Итог
- •3.2. Средства автоматизированного проектирования бд
- •3.2.1. Введение
- •3.2.2. Case-технологии
- •3.2.3. Достоинства case-технологий
- •3.2.4. Промежуточные выводы и определения
- •3.2.5. Методологии структурного моделирования
- •3.2.6. Методология sadt (idef0)
- •3.2.7. Методологии информационного моделирования
- •3.2.8. Нотация Чена
- •3.2.9. Нотация Мартина
- •3.2.10. Нотация ide1x
- •3.2.11. Нотация Баркера
- •3.2.12. Язык информационного моделирования
- •3.2.13. Case-средства
- •3.2.14. Процесс создания модели бд в ErWin
- •3.2.15. Процесс создания модели бд в Sparx ea
- •3.2.16. Итог
- •3.3. Особенности проектирования бд на логическом и физическом уровнях
- •3.3.1. Введение
- •3.3.2. Модель бд
- •3.3.4. Банки данных
- •3.3.5. Модели данных
- •3.3.6. Этапы проектирования бд
- •3.3.7. Проектирование бд: внешний уровень
- •Изучение процессов преобразования входных данных в выходные.
- •3.3.8. Проектирование бд: инфологический уровень
- •3.3.9. Проектирование бд: даталогический уровень
- •3.3.10. Уровни sql
- •3.3.11. Проектирование бд: физический уровень
- •3.4.3. Требования нормализации
- •3.4.4. Примеры аномалий
- •3.4.5. Нормальные формы
- •3.4.6. Зависимости
- •3.4.6. Первая нормальная форма
- •3.4.7. Вторая нормальная форма
- •3.4.8. Третья нормальная форма
- •3.4.9. Нормальная форма Бойса-Кодда
- •3.4.10. Четвёртая нормальная форма
- •3.4.11. Пятая нормальная форма
- •3.4.12. Доменно-ключевая нормальная форма
- •3.4.13. Ещё раз, кратко, все нормальные формы
- •3.4.14. Ещё раз, кратко, в ErWin
- •3.4.15. Обратное проектирование бд
- •3.4.16. Итог
- •3.5. Повышение качества бд на стадии проектирования
- •3.5.1. Памятки разработчикам бд
- •3.5.2. Показатели качества бд
- •Практическая часть
- •Указания по выбору варианта
- •Индивидуальные практические работы Индивидуальная практическая работа № 1 Общие сведения
- •Практическая часть
- •Указания по выбору варианта
- •Индивидуальная практическая работа № 2 Общие сведения
- •Указания по выбору варианта
- •Практическая часть
2.3.11. Консистентность данных
С понятием «ссылочной целостности» тесно связано понятие «консистентности данных».
Консистентность данных (data consistency, data validity) – согласованность данных друг с другом, целостность данных, а также внутренняя непротиворечивость.
Множество всех условий, налагаемых на данные определяется моделью (структурой) данных.
Данные представляют собой связанные отношениями узлы различного типа, и в модели данных могут быть оговорены условия: какие именно данные там могут хранится, и узлы каких типов могут быть связаны заданными в модели отношениями (связями).
Например, в базе данных людей, связь «родитель-ребёнок» направленная от узла «Родитель» к узлу «Ребёнок» подразумевает, что узел «Ребёнок» связан с «Родитель» либо как «дочь», либо как «сын», причём это непосредственно зависит от значения атрибута «пол» узла «Ребёнок».
Условия консистентности могут включать в себя указание того, какие значения могут принимать атрибуты узлов, какие отношения могут устанавливаться между узлами, каково минимальное и максимальное число отношений определённого типа, в котором может участвовать один узел, а также другие типы условий.
Условия целостности данных (integrity constraints) стали записывать в виде правил и ввели триггеры – процедуры, которые вызываются до и/или после выполнения запроса.
До запроса (триггер типа BEFORE) проходит проверка того, что данные имеют состояние, которое позволяет осуществить данный тип запроса.
После выполнения запроса (триггер типа AFTER) проверяется, что состояние базы данных удовлетворяет условиям целостности.
Если один из триггеров не срабатывает (или срабатывает с ошибкой), то транзакция откатывается (roll-back) (отменяется). Если же все триггеры сработали успешно, транзакция подтверждается (commit) (завершается).
При решении проблемы поддержки консистентности данных необходим разумный баланс между скоростью (сложностью алгоритмов) извлечения данных и скоростью (сложностью алгоритмов) хранения и модификации данных.
Более подробно вопрос формирования таблиц, связей, триггеров и т.п. мы рассмотрим, когда будем говорить о языке SQL.
Сейчас же мы рассмотрели основы этих вопросов и переходим к последовательному рассмотрению структуры БД…
2.4. Многоуровневая архитектура баз данных, понятие физического и логического уровней баз данных
2.4.1. Определения
Проектирование БД начинается с этапа «концептуального проектирования».
Концептуальное проектирование – это сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:
обследование предметной области, изучение её информационной структуры;
выявление всех фрагментов предметной области, каждый из которых характеризуется представлением, информационными объектами и связями между ними, процессами над информационными объектами;
моделирование и интеграция всех представлений.
По окончании этапа концептуального проектирования мы получаем «концептуальную модель», инвариантную (нечувствительную) к структуре базы данных.
Эта модель будет нас интересовать на «инфологическом уровне» схемы, представленной на следующем рисунке.
Часто такая модель представляется в виде модели «сущность-связь».
Следующий этап – логическое проектирование.
Логическое проектирование – преобразование требований к данным в структуры данных.
На выходе этого этапа мы получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ.
На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.
Эта модель будет нас интересовать на «даталогическом уровне» схемы, представленной на следующем рисунке.
Следующий этап – физическое проектирование.
Физическое проектирование – определение особенности хранения данных, методов доступа и т.д.
На выходе этого этапа мы получаем «физическую модель» базы данных.
Эта модель будет нас интересовать на «физическом уровне» схемы, представленной на следующем рисунке.
Различие уровней представления проще понять из того, кем они реализуется и что на них реализуется:
концептуальный (инфологический) уровень
реализуется аналитиком (используется инфологическая модель «сущность-связь»);
формируются сущности;
формируются атрибуты;
формируются связи.
логический (даталогический) уровень
реализуется программистом;
определяются записи;
определяются элементы и типы данных;
определяются способы организации связей между записями.
физический уровень
реализуется администратором;
определяется группирование данных;
определяются индексы;
определяются методы доступа.