- •Общие сведения Сведения об эумк
- •Методические рекомендации по изучению дисциплины
- •Рабочая учебная программа
- •Учреждение образования
- •«Белорусский государственный университет
- •Информатики и радиоэлектроники»
- •Пояснительная записка
- •Содержание дисциплины
- •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.4.3. Постоянная и переменная длина записи
Записи в файлах могут иметь постоянную и переменную длины.
Для файлов с постоянной длиной записи адрес размещения записи с некоторым номером K может быть вычислен по формуле:
ВА + (К- 1) * LZ + 1
где ВА – базовый адрес, LZ – длина записи.
Вопрос: что в таком случае сильнее всего влияет на скорость доступа к записи?
Ответ: особенности устройства. Так, например, у винчестеров время позиционирования и скорость линейного чтения могут зависеть от номера цилиндра.
Файлы прямого доступа обеспечивают наиболее быстрый доступ к произвольным записям, и их использование считается наиболее перспективным в системах баз данных.
Вопрос: чем плохи такие файлы?
Ответ: в реальных БД очень часто приходится хранить поля с переменной длиной («ФИО», «улица», «биография» и т.д.) Для хранения таких полей (пусть даже каждое поле таблицы хранится в своём отдельном файле, что часто – очень неэффективно) придётся отводить под каждую запись «максимально возможное количество байт», что приводит к потере памяти.
Файлы с переменной длиной записи почти всегда являются файлами последовательного доступа, либо требуют достаточно сложного механизма индексирования (об этом – чуть позже).
Такие файлы могут быть организованы двумя способами:
конец записи помечается специальным маркером;
в начале каждой записи записывается её длина.
В силу того, что каждая запись такого файла занимает произвольный объём памяти, простым вычислением получить адрес записи сразу и гарантированно – НЕВОЗМОЖНО.
2.4.4. Способы представления данных
Мы будем рассматривать способы представления данных на основе следующего примера. Допустим, нам нужно каким-то образом сохранить данные такой таблицы:
Рисунок 2.4.4.1 – Пример сохраняемой таблицы
В последующем предполагается (если только явно не указано обратное), что каждый хранимый файл упорядочен методом доступа по значению первичного ключа этого файла.
2.4.5. Простейший вариант – плоский файл
Простейший вариант представления предполагает использование единственного хранимого файла, содержащего по одному экземпляру записи для каждого поставщика.
Только что рассмотренный рисунок может служить иллюстрацией этого варианта представления.
Преимуществом данного варианта является его простота.
Недостатком является его неадекватность различным реальным ситуациям.
Предположим, например, что у нас есть 10000 поставщиков, и все они размещены только в 10 различных городах. В итоге мы «впустую» потратим большой объём памяти.
2.4.6. Факторизация по значениям поля
Если указатель занимает меньше памяти, чем название города, то вариант представления, изображённый на рисунке, позволит сэкономить некоторый объём памяти.
Рисунок 2.4.6.1 – Факторизация по значению поля
В данном случае у нас есть два хранимых файла: файл поставщиков и файл городов с указателями из первого во второй.
Эти указатели представляют собой адреса хранимых записей.
Единственным преимуществом этого варианта представления в сравнении с предыдущим является экономия памяти.
Но, например, запрос на поиск всех характеристик некоторого поставщика потребует по крайней мере одного дополнительного обращения к базе данных в сравнении о предыдущим случаем.
Также, запрос на поиск всех поставщиков, расположенных в некотором городе, будет включать несколько большее число операций доступа.
Следует отметить, что заботится об указателях СУБД, а не метод доступа; методу доступа связь между двумя файлами неизвестна.