Вы находитесь на странице: 1из 11

Пермский государственный университет механико-математический факультет

Базы данных (лекции)

Пермь, 2007

Лектор:

C. И. Чуприна

Набор, вёрстка:

П. С. Шучалов

Базы данных и экспертные системы (БД и ЭС)

Условный зачёт — сданы все задания, но низкого качества.

Во втором семестре будет курс ЭС, затем первая группа изучает БЗ и средства создания систем ИИ. Другие группы занимаются нейронными сетями.

Заранее нужно будет продумать тему для ЭС.

В России FoxPro лидирует как настольная СУБД. В нашем регионе часто FoxPro встречается на клиентской стороне, а на стороне сервера — другая СУБД.

Несколько слов о литературе:

Во-первых не покупайте никаких самоучителей по FoxPro, и тем более серию «Для чайников».

Хорошая старая книга: Менахем, Базилян.

Любая книга с фамилией Дейт, Ульман, Ш. Атре. Журнал СУБД в составе журнала Открытые системы. Лекции Кузнецова и Ладыженского. Есть электронный учебник Зеленкова.

§ 1. Введение в БД. Отличие СУБД от файловых систем.

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

Необходимо хорошо понимать, чем отличаются средства для работы с файлами от СУБД.

Рассмотрим отличия СУБД от файловых сисетм (Q&I, PC Files) на примере средств работы с файлами в традиционных языках программирования типа С, Pascal (тоесть с использованием структур типа struct и record).

Def. 1.: Под базой данных (БД) понимают организованную совокупность поименованых взаимосвязаных данных, предназначеных для многократного использования многими пользователями/приложениями.

В такой нотации это определение практически не отличается от определения файловой

системы. Однако, в случае, если одни и те же данные нужны сразу многим приложениям (даже не обязательно одновременно), необходимо переходить от использования ФС к использованию СУБД, так как только в СУБД гарантировано независимое использование данных от перикладных программ.

Рассмотрим примеры.

Пусть дан файл

1) [A|B|C|D|E] — у этого файла есть поля.

И существует уже законченное приложение(я) использущие этот файл.

Когда начинаются проблемы?

Если какому-то новому приложению понадобились данные из файла 1, то в случае использвания традиционных средств работы с файлами имеет места три варианта:

1) Мы просто добавляем данные в наш файл: [A|B|C|D|E|P|Q].

Что случится с существующим приложением? Его нужно будет переписывать хотя бы в месте ввода/вывода данных.

Даже в случае, если все данные будут строковые, то проблемы неизбежно возникнут.

В этом случае недостатком ФС является так называемый эффект спагетти: потянул за одну

макаронину, а вытащил целую кучу. Придётся переписывать ранее написаный программный код.

2) Можно скопировать первый файл, появится файл 2, который имеет ту же самую структуру: [A|B|C|D|E|P|Q].

В этом случае увеличивается избыточность данных, которая плоха ни только и ни столько

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

Гораздо лучше, когда общие данные для двуз приложений хранятся в одном месте.

3) Вместо того, чтобы копировать всё, копирует только ключь записи из файла 1: : [ключ из 1 файла|P|Q]. Самый лучший вариант, если заранее в файле 1 содержались т. н. искуственные ключи. Например, порядковые номера.

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

// :-) Не надо экономить на целых числах!

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

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

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

Вывод: в случае файловых систем сам разработчик вынужден писать специальные вспомогательные функции, которые собирают данные об одном информационном объекте из разных файлов с учётом разнийы в структуре, сортировке и т. д., тоесть это является негибким механизмом потому, что необходимо писать для доступа к разным данным специальное ПО (не унифицированное), и обращение к одному файлу и разным сильно отличаются.

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

Например, язык SQL — Srtuctured Query Language. Диалектов от SQL существует великое множество. К сожалению, они везде разные.

Главная причина, по которой средства работы с файлами в системах прогаммирования обладают перечисленными выше недостатками связана с тем, что описания данных хранятся и используются совместно с прикладными программами, а не независимо от них.

Данные действительно хранятся в отдельных файлах, но описания данных, даже если хранятся в отдельных файлах — во время исполнения это одно пространство.

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

Для этих целей СУБД имеют многоуровневую архитектуру.

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

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

контроль отключен).

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

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

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

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

БД можно рассматривать как такую совокупность данных, о которых конечные пользователи могут получить множество различных конечных _представлений_ (view).

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

// Понятие независимости данных обязательно для сдачи экзамена.

Данные следует рассматривать как важнейший и весьма дорогостоящий ресурс с собственным правовым статусом не зависимо от приходящих программ и аппаратуры.

§ 2. Многоуровневая архитектура современных СУБД.

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

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

КТi — это концептуальные требования i-го пользователя и/или приложения, описывающие обычно неформально на естественном языке (ЕЯ) необходимые ему данные. Эти неформальные требования лучше всё-таки оформить ввиде некоторой анкеты с обязательным указанием следующего:

Для каждого информационного объекта

— имя;

— состав атрибутов (реквизитов, характеристик, полей);

— связи с другими обхектами с указанием тех задач и документов, где эти связи надо учитывать.

Для этого от закащика желательно получить дополнительно копии всех отчётных документов: как входных, так и выходных и промежуточных. А для каждого атрибута желательно указать домен допустимых значений, ограничение целостности (условие на эти значения), а так же тип соответствия с другими атрибутами (1:1, 1:М, М:1, М:М).

При общении с конечным пользователем нужно получить описаную иномрацию, но перефразировать вопросы типа вместо «ограничение целостности» спросить просто перечень допустимых данных.

Следующий этап: КМ — концептуальная модель, которая представляет собой модель предметной области, описаную в терминах независящих ни от конкретной СУБД, ни, тем более, от особенности физиеской организации данных, и является интегрированным представлением КТi требований.

Интеграция — это не просто объединение, а такое совместное взаимосвязное описание данных, которое устраняет имеющиеся в разных КТi несоответствия и противоречия. Чаще всего на практике одну и ту же характеристику либо называют по-разному, либо наоборот разные вещи называют одинаково. При объединении требований необходимо провести их анализ и хранить в концептуальной модели только такие атрибуты, которые являются атрибутами-осованиями, а все остальные сделать вирутальными.

Например, какое-то КТ требует, чтобы в БД хранили возраст. Очевидно, что нужно хранить дату рождения, а какой-то виртуальный атрибут будет показывать вычисленный возраст.

ЛМ — логическая модель — это совместимый с конкретным типом СУБД вид концептуальной модели. Иными словами это концептуальная модель, записаная на языке описания данных конкретной СУБД.

ВМ — внешние модели (представления) соответствующие КТ требованиям, но записаные в нотации конкретной СУБД.

ВМi — это не просто некоторое подмножество логической модели (в ЛМ данные хранятся в номрализованом виде), а ненормализованное представление фрагмента логической модели с возможными преобразованиями.

ФМ — физическая модель — описание данных на физическом уровне, тоесть допустимые

структуры хранения, методы доступа (последовательный, индексно-последовательный, прямой), способы индексации.

.dbc, .dbx, .dbb — файлы, хранящие структуру данных — дата-контейнеры.

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

ФМ — это допустимые структуры хранения, методы доступа и способы индексации.

Физически-логическая независимость

Основной дополнительный вопрос на экзамене.

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

Логическая независимость данных означает, что изменение данных на логическом уровне не приводит к необходимости внесения изменений в ранее написаный программный код и в представления на внешнем уровне, которых эти изменения не касаются. Например, добавление новых столбцов даже в середину таблицы не повлияет на работу программы. То есть изменения на логическом уровне: добавление новых полей, добавление новых таблиц, связей, индексов — не приводит к изменениям на внешнем уровне.

Физическая независимость данных означает, что изменения на физическом уровне, то есть в структуре хранения данных на низком уровне, в медоты доступа (прямой, последовательный, индексно-последовательный), способы индексации — не приводит ни к изменениям на логическом уровне, ни на внешнем.

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

Например, в VFP при переходе от DOS-овских версий к визуальным в «шапку» .dbf файла добавилась ссыла на .dbc — Data Base Container, что не застаило изменять ранее написаные приложения.

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

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

§ 3. Нормализация

Нормализация — это пошаговый обратимый процесс декомпозиции исходных отношений на результирующие с последовательным устранением нежелательных функциональных зависимостей между данными.

Теория нормализации использует свойство реляционных таблиц.

Основные свойства реляционных таблиц:

1. Атомарность. Тоесть на пересечении любой строки и любого столбца таблицы должно находиться одно неделимое значение, а не группа или структурированные данные. Например, зачастую адрес хранят в таблице целиком в одной ячейке вместо того, чтобы разделять его по структуре (хотя иногда это соответствует требованиям программы и является нормальным).

2. Уникальность. Не должно быть (в любой таблице) двух одинаковых кортежей 1 .

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

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

Понятие функциональной зависимости

Пусть A и B — две совокупности аттрибутов некоторого отношения R. Говорят, что

если в любой момент времени каждому набору значений из A соответствует ровно один

набор значений из B. Но функциональные зависимости (ФЗ) бывают разного типа, и в процессе нормализации устраняются только нежелательные ФЗ.

Нежелательными являются все избыточные ФЗ:

A B

частичная

транзитивная

многозначная

зависимость по соединению

т. д.

,

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

Первичный ключ — это минимальная совокупность атрибутов, однозначно определяющая любой кортеж отношения.

Мы будем использовать нормализацию на основе универсального отношения, то есть предварительно (перед первой нормальной формой) все атрибуты, если их не больше 30, помещаются в одну таблицу и заполняется контрольный пример. Контрольный пример должен содержать такой подмножество данных, которое демонстрирует все возможные типовые ситуации (связи). Сами данные могут быть не реальные, но обязательно с сохранением смысла и типа.

Любое длинное символьное название сопровождается в БД уникальным искуственным

ключём, который по смыслу заменяет это название.

Отношение находится в первой нормальной форме, если в нём устранены повторяющиеся группы данных и определён первичный ключ. Выписывать ФЗ обязательно.

Фрагмент предметной области — счёт-фактура. Считаем, что номер счёт-фактуры уникален.

[*] №

Дата

Назва

Адрес

Лицев

Номер

Назва

Адрес

[*] №

Назва

Ед.

Цена

Колич

сч.-ф.

постав

ние

постав

ой

банка

ние

банка

товара

ние

изм.

за ед.

ество

щика

постав

щика

счёт

банка

щика

1

01.01.0

1

«Луна»

а1

1

1

«Банк»

01

1

«Товар

шт.

1,2

100

1

»

20

01.02.0

1

«Луна»

а1

1

1

«Банк»

01

1

«Товар

шт.

3,4

200

1

»

20

01.02.0

1

«Луна»

а1

1

1

«Банк»

01

2

«Товар

кг

6,7

50

1

два»

2

01.01.0

2

«Солн

а2

3

1

«Банк»

01

1

«Товар

шт.

1,2

120

1

це»

»

100

01.05.0

3

«Земля

а3

5

2

«Банк

аб5

1

«Товар

шт.

1,0

800

1

»

два»

»

Считаем, что с конкретным поставщиком работаем только через один банк.

В случае универсального отношения от повторяющихся групп избавляемся путём копирования соответствующих данных в пустых ячейках.

Зная номер счёт-фактуры можно однозначно определить дату, номер поставщика, название поставщика, адрес поставщика, лицевой счёт, номер банка, название банка, адрес банка.

Далее номер поставщика однозначно определяет название поставщика, адрес поставщика, лицевой счёт, номер банка, название банка, адрес банка.

В свою очередь номер банка однозначно определяет название банка, адрес банка.

Номер счёта-фактуры и номер товара однозначно определят строку, в которой указаны цена и количество товара.

Первичный ключ — номер счёта фактуры, номер товара.

Алгоритм нормализации — получение нормальной формы — выделение всех функциональных зависимостей.

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

1. № с. ф. адрес банка.

Дата, № пост., Название поставщика, Адрес, Лицевой счёт, номер банка,

2. № пост.

Название, Адрес, Лицевой счёт, Номер банка, Адрес банка.

3. № банка

Название банка, Адрес банка.

4.

№ товара

Наименование, Ед. изм.

5. № с. ф., № товара

Цена, количество.

Аномалии первой нормальной формы

1. Аномалия изменения.

Связана, например, с изменением реквизитов поставщика.

Изменяя реквизиты поставщика, банка, необходимо просканировать всю БД и внести изменения в данные всех счетов-фактур этого поставщика или этого банка.

2.

Аномалия вставки.

Невозможно добавить информацию о поставщике, товаре или банке не занося данные о счёте-фактуре с соответствующими реквизитами.

3. Аномалия удаления.

Удаляя данные, например, о поставщике (предположим, мы не хотим больше иметь с ним дело), удаляем записи всех счетов-фактур с этим поставщиком (это не аномально!), но при этом могут быть потеряны сведения о банке и о товаре, если в счетах-фактурах других поставщиков нет этих данных. То же самое касается случаев, когда хотим удалить банк или товар.

Чтобы устранить аномалии, связаные с частичными функциональными зависимостями, построим вторую нормальную форму.

Отношение находиться во второй нормальной форме, если оно находиться в первой нормальной форме и в неё устранены частичные функциональные зависимости, то есть зависимости от части ключа.

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

Все вновь получившиеся отношения должны быть поименованы и иметь первичный ключ.

Выделяем первую и четвёртую функциональные зависимости.

Таблица 1: Шапка счёта-фактуры

[*] № сч.-ф.

Дата

№ поставщика

Название

Адрес

Лицевой

Номер

Название

Адрес

поставщика

поставщика

счёт

банка

банка

банка

Таблица 2: Товар

 

[*] № товара

Название

Ед. изм.

 

Таблица 3: Счёт-фактура

[*] № сч.-ф.

[*] № товара

Цена

Количество

После устранения частичных зависимостей в нашем примере пропали только аномалии, связаные с данными о товарах. Аномалии, связаные с данными о поставщиках и бакнах остались транзитивными.

Транзитивная функциональная зависимость. Пусть A, B, C — три совокупности

атрибутов отношения. Говорят, что A транзитивно определяет C, или что C транзитивно

зависит от A, если

Третья нормальная форма — это вторая нормальная форма, в которой устранены транзитивные ФЗ. Для того, чтобы устранить транзитивные ФЗ, выносятся в отдельные отношения те атрибуты, которые входят в состав транзитивных ФЗ.

Определяем первичный ключ этого нового отношения. При этом в исходном отношении помимо его ключа и атрибутов, не участвующих в транзитивной ФЗ, остаётся ключ этого нового отношения (для связи).

Номер поставщика зависит от номера счёта-фактуры, а номер банка зависит от номера поставщика.

A B

B C

,

.

Таблица 1: Поставщик

[*] № поставщика

Название поставщика

Адрес

Лицевой счёт

№ банка

Название

Адрес банка

поставщика

банка

Таблица 2: Шапка

[*] № сч.-ф.

Дата

№ поставщика

Таблица 3: Товар

[*] № товара

Название

Ед. изм.

Таблица 4: Счёт-фактура

[*] № сч.-ф.

[*] № товара

Цена

Количество

Устраняем зависимость между поставщиком и банком.

Таблица 5: Банк

[*] № банка

Название банка

Адрес банка

Таблица 6: Поставщик

[*] № поставщика

Название поставщика

Адрес поставщика

Лицевой счёт

№ банка

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

Алгоритм нормализации гарантирует минимальную избыточность хранения данных, так как в ходе нормализации устраняются все избыточные ФЗ и остаётся полная ФЗ неключевых атрибутов от ключа.

Задание: получившиеся таблицы заполнить данными из контрольного примера и увидеть отсутствие аномалий.

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

На контрольной работе нужно будет:

1. Построить универсальное отношение и контольный пример.

1. Построить ФЗ.

2. Определить первичный ключ.

2. Построить вторую нормальную форму.

Не нужно устранять транзитивные ФЗ.

3. Построить третью нормальную форму.

Устранить сначала обхемлющие транзитивные ФЗ, потом вычленить остальные.

Рекомендуется проверить третью нормальную форму объединив полученые таблицы в один кортеж и получить исходную таблицу.

Для новых отношений нужно всегда определять название отношений и первичный ключ.