
- •Проектирование баз данных. Лекция 1. Введение. Банки и базы данных. Архитектура субд.
- •Хранимая база данных (Внутренняя модель)
- •Понятие проектирования баз данных. Различные подходы к проектированию бд.
- •Различные подходы к проектированию данных.
- •Сетевая модель данных.
- •Лекция 2.
- •Реляционные операции над отношениями.
- •Лекция 3. Аномалии хранения данных.
- •Концептуальное проектирование данных. Нормализация. Понятие функциональной зависимости. Теорема Хита.
- •Функциональная зависимость.
- •Теорема Хита.
- •Лекция 4. Пятая нф. Универсальное отношение. I и II нф.
- •Первая нормальная форма.
- •Вторая нормальная форма.
- •Третья нормальная форма. Транзитивные зависимости.
- •Лекция 5. Нормальная форма Бойса-Кодда. Четвертая нормальная форма. «Перенормализованные» модели данных.
- •Четвертая нормальная форма.
- •«Перенормализованные» модели данных.
- •Пример проектирования бд.
- •Отношение “Аптека”
- •Отношение “Лекарство”
- •Отношение “Наличие лекарств”
- •Отношение “Поставщик”
- •Отношение “Лицензия поставщика”
- •Отношение “Запрос на поставку”
- •Лекция 6. Проектирование в терминах «Сущность – связь»
- •Сущности и связи.
- •Классификация связей
- •Предварительные отношения для бинарных связей степени 1:1.
- •Лекция 7. Предварительные отношения для степени связи 1:n и m:n.
- •Предварительные отношения для степени связи m:n.
- •Лекция 14. Предварительные отношения для связей высших порядков. Использование ролевых отношений.
- •Студент
- •Использование ролевых отношений.
- •Рабочий
- •Подчиненный
- •Лекция 8. Развитой пример применения e-r проектирования.
- •Сопоставление методик нормализации и e-r проектирования. Физическое проектирование.
- •Физическое проектирование.
- •Ограничения целостности.
- •Заключение.
Понятие проектирования баз данных. Различные подходы к проектированию бд.
Под проектированием базы данных будем понимать разработку структуры информационной модели предметной области, а также разработку особенностей реализации этой модели.
Задачу проектирования баз данных можно определить следующим образом. В качестве исходных данных задана неформализованный набор сведений о предметной области. На основании этого необходимо организовать хранение данных о состоянии предметной области в такой форме, которая обеспечила бы непротиворечивость хранимой информации и максимальное удобство ее обработки. База данных время от времени может подвергаться модернизации структур хранения данных и сама структура ее должна обеспечивать минимальный объем изменений в работе всего банка данных при подобной модернизации.
В создании информационного обеспечения банка данных проектирование БД предшествует разработке приложений и является одним из отправных пунктов для формулировки технических заданий на разработку приложений.
Различные подходы к проектированию данных.
Прежде, чем говорить об особенностях отображения предметной области в базе данных необходимо договориться об общих принципах представления информации. Способ отображения данных с помощью какой – либо СУБД будем называть моделью данных (представлением данных). Всего известно три принципиально различных модели данных – реляционная, иерархическая и сетевая.
Примечание для начинающих. Не путать сетевую модель данных с расположением данных в вычислительной сети. Эти два понятия не имеют между собой ничего общего.
Реляционная модель данных.
Рассмотрим следующую группу таблиц (рис.2). Эта база данных содержит данные о деталях, используемых какой- либо организацией, поставщиках, в том числе и потенциальных и поставках деталей от поставщиков. Заметим, что таблицы Детали и Поставки имеют столбцы, определенные на общем множестве данных (код детали); то же относится к столбцам «код поставщика» в таблицах Поставки и Поставщики. Основным свойством реляционных структур данных является то, что связи между строками таблиц представлены исключительно значениями данных в столбцах, принадлежащих общему множеству (домену). Тот факт, что партия поставки №130 получена от поставщика2 представлен одинаковыми значениями атрибута код поставщика.
Детали
Поставщики
-
Код поставщика
Наименование
Поставщика
город
Код детали
Наименование детали
Материал
Вес
1
Поставщик1
Тула
10
Болт
Сталь
140
2
Поставщик2
Москва
20
Гайка
Бронза
75
3
Поставщик3
Лондон
30
Втулка
Резина
80
40
Ось
Сталь
200
Поставки
-
Код поставщика
Код детали
Код партии поставки
Количество
1
10
120
100
1
10
121
300
2
10
130
10
2
30
135
50
2
40
140
1000
3
20
122
30
3
10
188
500
3
10
202
100
Рис. 2. Пример представления данных в реляционной форме.
Особенность реляционного представления данных состоит в том, что вся информация представлена в единой, унифицированной форме. Это касается как объектов, так и связей между ними. Собственно говоря, понятие связи между отношениями в реляционной модели данных отсутствует, и может быть реализовано лишь на логическом уровне – на уровне реализации и разработки приложений. Представление каждого отношения на физическом уровне файлом или набором файлов позволяет легко изменять, наращивать, «масштабировать» информационную модель путем всего лишь добавления новых файлов отношений. Эта гибкость представления данных обеспечивается равноправием всех атрибутов – как ключевых, по которым осуществляется связь между отношениями, так и неключевых. Оборотной стороной этой гибкости является более сложная обработка данных при операциях доступа.
Иерархическая модель данных.
В рамках этой модели данные организуются в форме древовидного графа (см. рис 3). Пользователь представляет данные в виде экземпляров иерархии, в данном случае – четыре отдельных дерева, соответствующих деталям. Каждый экземпляр записи поставщика включает соответствующую величину, характеризующую величину поставки. Записи в вершине дерева (детали) обычно называют «корнем». Заметим, что набор порожденных записей для данного экземпляра корневой записи может содержать любое количество записей, в том числе и нуль. Вообще, корень может иметь произвольное число подчиненных элементов, для каждого из которых, в свою очередь, возможно существование произвольного количества подчиненных элементов более низкого уровня, и т.д. для произвольного количества уровней.
В предыдущем примере мы уподобили реляционную модель набору отдельных файлов. По аналогии, можно уподобить иерархическую модель единственному файлу, содержащему наборы разнотипных записей, а также связи (ссылки) между записями разного уровня.
Принципиальным отличием между реляционным и иерархическим представлением данных являются более жесткие ограничения на доступ к информации. Доступ к любым данным возможен только через корень дерева, и для доступа к конкретной записи необходимо задать маршрут доступа. Это обеспечивает очень высокое быстродействие такой модели на так называемых прямых запросах, т.е. таких, при которых направление поиска совпадает с направлением ребер древовидного графа. В приведенной на рис.3 схеме примером прямого запроса может быть поиск количества болтов, закупленных у поставщика3. Теоретически, на реализации прямых запросов СУБД иерархического типа способны обеспечить максимальную скорость поиска по сравнению с сетевыми и реляционными. Однако, для ответа на вопрос типа «какие детали были закуплены у поставщика1?» понадобится гораздо большее количество поисковых операций. Такой запрос называется инверсным.
-
10
Болт
Сталь
140
-
1
120
100
Поставщик1
1
121
300
Поставщик1
2
130
10
Поставщик1
3
188
500
Поставщик3
3
202
100
Поставщик3
-
20
Гайка
Бронза
75
-
3
122
30
Поставщик3
Рис. 3. Пример данных в иерархической форме.