Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Проектирование баз данных.doc
Скачиваний:
1
Добавлен:
01.07.2025
Размер:
1.03 Mб
Скачать

Понятие проектирования баз данных. Различные подходы к проектированию бд.

Под проектированием базы данных будем понимать разработку структуры информационной модели предметной области, а также разработку особенностей реализации этой модели.

Задачу проектирования баз данных можно определить следующим образом. В качестве исходных данных задана неформализованный набор сведений о предметной области. На основании этого необходимо организовать хранение данных о состоянии предметной области в такой форме, которая обеспечила бы непротиворечивость хранимой информации и максимальное удобство ее обработки. База данных время от времени может подвергаться модернизации структур хранения данных и сама структура ее должна обеспечивать минимальный объем изменений в работе всего банка данных при подобной модернизации.

В создании информационного обеспечения банка данных проектирование БД предшествует разработке приложений и является одним из отправных пунктов для формулировки технических заданий на разработку приложений.

Различные подходы к проектированию данных.

Прежде, чем говорить об особенностях отображения предметной области в базе данных необходимо договориться об общих принципах представления информации. Способ отображения данных с помощью какой – либо СУБД будем называть моделью данных (представлением данных). Всего известно три принципиально различных модели данных – реляционная, иерархическая и сетевая.

Примечание для начинающих. Не путать сетевую модель данных с расположением данных в вычислительной сети. Эти два понятия не имеют между собой ничего общего.

Реляционная модель данных.

Рассмотрим следующую группу таблиц (рис.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. Пример данных в иерархической форме.