Geum.ru

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

Вид материалаДиплом

Содержание


Упражнения и вопросы для самоконтроля
2. Постановка задачи проектирования реляционных баз данных на основе использования информации табличного вида
Подобный материал:
1   2   3   4   5   6   7   8   9   ...   28

Упражнения и вопросы для самоконтроля




  1. Что такое информация табличного вида?
  2. Какие существуют формы представления информации табличного вида?
  3. Какие проблемы возникают при импорте информации табличного вида в БД?
  4. Какие существуют мотивы преобразования информации табличного вида в таблицы БД?
  5. В чем актуальность преобразования информации табличного вида в таблицы БД?
  6. Сформулируйте основные требования к средствам преобразования информации табличного вида в таблицы БД.
  7. Сформулируйте задачи объединения и разбиения реляционных таблиц.
  8. Сформулируйте задачи нормализации реляционных таблиц.
  9. Когда возникает необходимость преобразования электронных таблиц в форматы таблиц БД?






2. ПОСТАНОВКА ЗАДАЧИ ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ НА ОСНОВЕ ИСПОЛЬЗОВАНИЯ ИНФОРМАЦИИ ТАБЛИЧНОГО ВИДА

2.1. Укрупненная модель реляционной базы данных



БД – это взаимосвязанные объекты данных. К объектам БД относятся таблицы, индексы, ключи, представления.

К СУБД относятся хранимые процедуры, формы, отчеты, макросы.

Кроме БД и СУБД имеются инструментальные средства, в рамках которых и посредством которых разрабатываются БД и СУБД. К ним относятся такие системы как Oracle, Microsoft SQL Server, Microsoft Access, Clarion и многие другие. Эти системы также нередко называют СУБД. И в этом есть резон, так как, во-первых, посредством этих систем разрабатываются БД и СУБД, а, во-вторых, БД и СУБД функционируют под управлением этих систем.

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

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

Инструментальные средства


БД

СУБД






Пользователь БД

Пользователь БД

…

Рис. 2.1. Основные компоненты баз данных


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

Задача состоит в том, чтобы спроектировать БД в принятом аспекте этого понятия. На рис. 2.2 приведено схематичное представление такого рода БД.





Предметная область


Т1 Т2 ТL

К.Т1
1 1
К.Т2
… 1 
K.TL

П1.Т1
П1.Т2
П1.TL

…
…
…

ПN.Т1
ПK.Т2
ПM.TL


TF TZ

K1.TF
1 

K.TZ

K2.TF

П1.TZ

…
…

…
ПN.TZ




Рис 2.2. Схематичное представление БД


На рисунке изображены структуры таблиц и все возможные связи между ними.

Здесь префикс ”К” означает ключ (ключевое поле). В принципе ключ может содержать несколько полей, но для компактности схемы такие ситуации не показаны.

На схеме приведены возможные связи. '1’ означает связь одного значения поля, ‘’ означает связь с несколькими значениями поля. Таким образом отображены все возможные типы связей – “1 : 1”; “1 : ”; “ : 1”; “ : ” (Эта связь реализована посредством таблицы TF). Связь “ : 1” – это связь “1 : ”, если рассматривать таблицы в другом порядке.

Таким образом, укрупненную модель БД можно представить в следующем виде: T = {T1, T2,…,Тi,…,Тк}, где

Тi – i-я реляционная нормализованная таблица БД;

к – число таблиц в БД;


Ti = (Ki, Пi1, Пi2,…, Пij,…, Пin,), где

Ki – ключевое поле i- ой таблицы;

Пij – j –ое поле i-ой таблицы;

n – число неключевых полей;

Ti соответствует предметной области.

S = (S1, S2, …, Sj, …, Sm), где

Sj – связь между таблицами;

m - число связей.

Обозначим:

T(Sj) = (Tj1, Tj2) - пара таблиц инцидентных связи Sj;

N (Sj) = “1:1”  “1: ”  “  : 1”  “  :  ” – тип связи.

Таким образом, проектирование БД сводится к построению описанной модели, а затем реализация БД на основе этой модели с использованием соответствующих инструментальных средств.

В литературе, посвященной теории и практике проектирования БД широко освящены задачи проектирования, этапы проектирования БД, требования к БД и способы реализации этих требований [2]. Пользуясь сложившейся теорией проектирования БД, можно в приемлемые сроки разработать модель БД и реализовать БД, удовлетворяющую требованиям непротиворечивости, минимальности, целостности.

Целью проектирования БД является построение и реализация ее модели. Способ проектирования – использование сложившейся методики построения БД. Результат проектирования – эффективные, взаимосвязанные структуры данных.

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

В связи с этим насущной проблемой является разработка методики проектирования БД на основе использования заполненных нереляционных таблиц.

Проектирование реляционных структур данных и связей между ними на основе существующей теории имеет ряд основополагающих достоинств.

1. Теория предполагает выполнение этапов проектирования: анализ требований, инфологическое проектирование, датологическое проектирование, физическое проектирование [1-3]. Последовательно решая задачи названных этапов проектирования, разработчик БД проектирует структуры данных начиная с логических и кончая физическими. Причем на каждом этапе решаются задачи, ориентированные на достижение наилучших характеристик БД.

2. В соответствии с теорией разрабатываются структуры данных, соответствующие требованиям к реляционным таблицам. Эти структуры органично вписываются в концепцию реляционных БД.

3. В соответствии с теорией формулируются требования к нормализации реляционных таблиц. Выполняя эти требования, разработчик обеспечивает непротиворечивость и минимальность БД.

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

В случае проектирования БД на основе заполненных таблиц достоинства существующей теории практически сводятся к нулю.

1. О выполнении этапов проектирования практически не может быть и речи, так как таблицы уже заполнены, и проектировать новые логические структуры не имеет смысла.

2. Структуры данных заполненных таблиц, как правило, не отвечают требованиям к реляционным таблицам – приходится исходить из того, что есть.

3. В подавляющем большинстве случаев таблицы, построенные и заполненные вне баз данных, не нормализованы.

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

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