- •Проектирование баз данных. Лекция 1. Введение. Банки и базы данных. Архитектура субд.
- •Хранимая база данных (Внутренняя модель)
- •Понятие проектирования баз данных. Различные подходы к проектированию бд.
- •Различные подходы к проектированию данных.
- •Сетевая модель данных.
- •Лекция 2.
- •Реляционные операции над отношениями.
- •Лекция 3. Аномалии хранения данных.
- •Концептуальное проектирование данных. Нормализация. Понятие функциональной зависимости. Теорема Хита.
- •Функциональная зависимость.
- •Теорема Хита.
- •Лекция 4. Пятая нф. Универсальное отношение. I и II нф.
- •Первая нормальная форма.
- •Вторая нормальная форма.
- •Третья нормальная форма. Транзитивные зависимости.
- •Лекция 5. Нормальная форма Бойса-Кодда. Четвертая нормальная форма. «Перенормализованные» модели данных.
- •Четвертая нормальная форма.
- •«Перенормализованные» модели данных.
- •Пример проектирования бд.
- •Отношение “Аптека”
- •Отношение “Лекарство”
- •Отношение “Наличие лекарств”
- •Отношение “Поставщик”
- •Отношение “Лицензия поставщика”
- •Отношение “Запрос на поставку”
- •Лекция 6. Проектирование в терминах «Сущность – связь»
- •Сущности и связи.
- •Классификация связей
- •Предварительные отношения для бинарных связей степени 1:1.
- •Лекция 7. Предварительные отношения для степени связи 1:n и m:n.
- •Предварительные отношения для степени связи m:n.
- •Лекция 14. Предварительные отношения для связей высших порядков. Использование ролевых отношений.
- •Студент
- •Использование ролевых отношений.
- •Рабочий
- •Подчиненный
- •Лекция 8. Развитой пример применения e-r проектирования.
- •Сопоставление методик нормализации и e-r проектирования. Физическое проектирование.
- •Физическое проектирование.
- •Ограничения целостности.
- •Заключение.
Хранимая база данных (Внутренняя модель)
Рис. 1. Архитектура системы баз данных.
Физический уровень хранения данных – это способ представления информации непосредственно на машинном носителе. Обработка такой информации, или, как говорят, доступ к БД, осуществляется с помощью специфичных механизмов доступа к данным. Наличие таких механизмов, собственно, и отличает СУБД от других классов прикладного программного обеспечения. Если вернуться к рис. 1, то уровень механизмов доступа к данным соответствует отображению «концептуальный – внутренний».
Концептуальная модель данных – это представление данных, свободное от особенностей физической реализации. Современные СУБД используют для представления понятие таблицы. Таблица СУБД близка к типизированному файлу записей, применяемому во многих языках программирования, хотя есть некоторые отличия, которые будут рассмотрены ниже. База данных представима как набор таблиц. На этом уровне термин «модель данных» означает описание полей таблиц, входящих в БД. Структуру таблицы на физическом уровне (на уровне файлов) рассмотрим на примере весьма популярного формата DBF.
Таблица может состоять из нескольких файлов. «Главным» среди них является файл, имеющий расширение DBF (откуда и название формата). Имя этого файла является именем таблицы. Он собственно и образует таблицу, все остальные файлы выполняют скорее вспомогательные функции. В заголовке DBF- файла содержится описание всей таблицы, в первую очередь – описание имен, типов и длины полей. Кроме этого, заголовок описывает и некоторую служебную информацию, например, модификацию формата, кодовую страницу (для Windows), количество записей в таблице и пр. Далее в DBF файле следуют собственно записи, без каких – либо разделителей. Кроме того, в состав таблицы может входить файл, имя которого совпадает с именем таблицы, и имеющий расширение .FPT. Здесь находится содержимое MEMO- полей, или полей комментариев; их хранение вместе с основной таблицей привело бы к неоправданному увеличению ее размера. Кроме этого, в состав таблицы еще входят файлы с индексами. Посредством индексирования организуется прямой доступ к записям таблицы. В зависимости от формата и используемой СУБД возможен либо один составной (compound) индексный файл, либо несколько отдельных для каждого из индексов (в случае с FoxPro – соответственно CDX и IDX файлы)
Для работы конечных пользователей обеспечивается доступ к данным через приложения, т.е. прикладные программы, использующие средства доступа к данным. Естественно, что в рамках банка данных количество решаемых подзадач может быть достаточно велико, соответственно, возможно использование нескольких приложений. Различные приложения могут использовать различные подмножества данных концептуального уровня. Такое подмножество называют внешней моделью данных.
Основной задачей прикладного программиста при работе в среде СУБД является не работа с данными как с таковыми, а создание прикладных программ для передачи их конечному пользователю. Уже поэтому любой пакет СУБД должен иметь в своем составе среду разработчика, включая средства отладки и трассировки. Кроме того, должна быть предусмотрена поддержка выполнения приложений (run-time) , поскольку запуск приложений из среды разработчика неудобен для пользователя. Как правило, такая поддержка реализуется в виде постоянно (в течение выполнения приложений) присутствующего в памяти ядра СУБД, которое предоставляет пользовательским приложениям возможность обращения к командам и функциям СУБД, осуществляя таким образом доступ к данным.
Из сказанного естественным образом следует, что этапу разработки приложений, с помощью которых будет осуществляться работа банка данных должен предшествовать этап разработки структуры таблиц или проектирование базы данных.
