Работа с базами данных
Характеристика реляционной, иерархической и сетевой моделей баз данных. Анализ методов проектирования (декомпозиция, синтез, объектная связь), организации, обновления, восстановления, ограничений, поддержания целостности данных на примере СУБД Ms Access.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 13.02.2010 |
| Размер файла | 347,4 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
III этап. Синтез модели
На этом этапе по проведенному выше анализу необходимо выбрать определенную модель БД. Далее рассматриваются достоинства и недостатки каждой модели, сопоставить их с требованиями и задачами вашей БД и выбрать ту модель, которая сможет максимально обеспечить реализацию поставленной задачи. После выбора модели необходимо нарисовать ее схему с указанием связей между таблицами или узлами.
IV этап. Способы представления информации, программный инструментарий
После создания модели необходимо, в зависимости от выбранного программного продукта, определить форму представления информации. В большинстве СУБД данные можно хранить в двух видах:
С использованием форм;
Без использования форм.
Форма - созданный пользователем графический интерфейс для ввода данных в базу.
V этап. Синтез компьютерной модели объекта и технология его создания
После рассмотрения инструментальных возможностей выбранного программного продукта можно приступить к реализации БД на компьютере. В процессе создания компьютерной модели можно выделить некоторые стадии, типичные для любой СУБД.
Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы
В процессе выполнения данной стадии необходимо запустить СУБД, создать новый файл (новую базу) или открыть существующую.
Стадия 2. Создание исходной таблицы или таблиц.
Создавая исходную таблицу, необходимо указать имя и тип каждого поля. Имена полей не должны повторяться внутри одной таблицы. В процессе работы с БД можно дополнять таблицу новыми полями. Созданную таблицу необходимо сохранить, дав ей имя, уникальное в пределах создаваемой базы.
Стадия 3. Создание экранных форм.
Первоначально необходимо указать таблицу, на базе которой будет создаваться форма. Ее можно создавать при помощи Мастера форм или самостоятельно, указав, какой вид она должна иметь (например, в виде столбца или таблицы). При создании формы можно указывать не все поля, которые содержит таблица, а только некоторые из них. Имя формы может совпадать с именем таблицы, на базе которой она создана. На основе одной таблицы можно создать несколько форм, которые могут отличаться видом или количеством используемых из данной таблицы полей. После создания форму необходимо сохранить. Созданную форму можно редактировать, изменяя местоположение, размеры и формат полей.
Стадия 4. Заполнение БД.
Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE - в виде формы.
VI этап. Работа с созданной базой данных
Работа с БД включает в себя такие действия, как:
Поиск необходимых сведений;
Сортировка данных;
Отбор данных;
Вывод на печать;
Изменение и дополнение данных.
Рассмотрим все этапы создания и принципы работы с базами данных на примере СУБД Microsoft Access.
2.1 Методы проектирования реляционной БД
Когда перечень атрибутов составлен, очередная задача состоит в их агрегации, то есть компоновке атрибутов в объекты. Это и есть суть процесса проектирования реляционной базы данных.
Существует несколько подходов к проектированию РБД.
Декомпозиция (для небольших БД);
Синтез;
Использование модели объекта связи (метод ER-диаграмм).
2.1.1 Метод декомпозиции
Характеризуется тем, что сначала создается одно УО, которое затем разбивается на ряд отношений, находящихся в НФ. Использование таблицы кажется на первый взгляд удобным, на самом деле при работе с такой таблицей возникают аномалии обновления.
Возможный ключ -- представляет собой атрибут или набор атрибутов, который может быть использован для данного отношения в качестве первичного ключа.
Детерминант -- если А=>В -- ФЗ и В не зависит функционально от любого подмножества А, то говорят, что А представляет собой детерминант В.
Большинство потенциальных аномалий в БД будет устранено при декомпозиции любого отношения в НФБК.
Отношение находится в НФБК, если и только если каждый детерминант отношения является возможным ключом.
Пример:
Функциональные зависимости:
Диаграмма ФЗ:
Из диаграммы видно, что УО на находится ни в 2НФ, ни в 3НФ.
Расположим рядом перечень всех детерминантов и всех возможных ключей.
|
Возможный ключ |
Детерминант |
|
|
1. Таб№, Имя_Р |
Таб№, Имя_Р, ФИО Отдел Таб№ Телефон |
Поскольку не каждый детерминант в данном отношении является возможным ключом, следовательно, отношение "сотрудник" не находится в НФБК и его нужно подвергнуть декомпозиции.
Общий подход декомпозиции заключается в следующих шагах:
Разработка универсального отношения БД; для построенного УО находится первичный ключ.
Определение всех ФЗ между атрибутами отношения;
Определение того, находится ли отношение в НФБК, если да, то проектирование завершается, если нет, то отношение должно быть разбито на два.
Повторение шагов 2) и 3) для каждого нового отношения, построенного в результате декомпозиции.
Разбиение отношения на два отношения на шаге 2) осуществляется по следующему правилу.
Пусть отношение не находится в НФБК. Определяется ФЗ, например, , которое является причиной того, что r не находится в НФБК, т.е. С является детерминантом но не является возможным ключом.
Создаются два новых отношения, и , где зависимая часть была выделена из отношения и опущена при формировании отношения r1, и полностью использована при формировании отношения r2. Теперь нужно проверить, находится ли полученное отношение в НФБК. Про отношение говорят, что оно является проекцией отношения r. Этот тип декомпозиции называется декомпозицией без потерь.
На этом же этапе должно быть принято решение, какую ФЗ выбрать для проведения первой проекции. Не исключено, что в итоге выбора той или иной I (начальной) проекции будут получены разные БД. Простым правилом выбора … , с последующим использованием для I проекции правой зависимости (). Если таких цепочек нет, то безразлично, с чего начинать.
Это правило можно сформулировать и так: следует избегать выбора ФЗ, правая часть которой сама (целиком или частично), является детерминантом другой ФЗ.
Отношение, получаемое в результате декомпозиции, должно удовлетворять требованиям:
Возможность восстановить в точности исходное отношение путем естественного соединения отношений -- результатов декомпозиции;
Сохранение всех ФЗ исходного отношения.
Пусть в отношении r со схемой R имеется множество ФЗ. Говорят, что схема R разложима без потерь на отношения с сохранением ФЗ, если для любого кортежа . Кортеж может быть восстановлен
соединением его проекций. Невыполнение этих требований приведет к получению набора отношений, порождающих не согласующиеся данные.
Условия разложения без потерь:
а) для разложения, состоящего из двух отношений. Если отношение R1 и R2 являются разложением с сохранением множества ФЗ, это разложение обеспечивает соединение без потерь, если либо . Здесь операции " " и " - " определены над списками атрибутов отношений. Это правило можно сформулировать по-другому: отсутствие потерь при декомпозиции гарантируется, если от общего атрибута двух получаемых отношений зависит хотя бы один атрибут из двух оставшихся.
б) для разложения, состоящего более чем из двух отношений (метод табло). Процедура состоит в построении таблицы, строками которой являются имена, полученные при декомпозиции отношений, а столбцы -- список атрибутов этих отношений без повторений. Таблица заполняется символами , если элемент i-й строки в j-м столбце соответствует атрибуту Aj в отношении Ri, в противном случае ничего не ставится. После заполнения таблицы следует итеративный просмотр всех ФЗ . Если для атрибутов из Х найдутся строки, где в соответствующих местах стоят aj, то пустые элементы этих строк, соответствующие столбцам атрибутов из Y, заменяются на aj*. Если в результате появится строка таблицы, заполненная полностью aj и aj*, то данное соединение без потерь. В противном случае -- с потерями.
Метод декомпозиции применим для задач с малым числом атрибутов и отношений.
2.1.2 Метод синтеза
Отметим еще одно важное правило, лежащее в основе метода синтеза.
Все ФЗ с одинаковыми детерминантами нужно выделять в одну группу и каждой такой группе отводить свои собственные отношения. Получаемые отношения проверяются на соответствие с НФБК.
Этот прием следует применять в том случае, когда использование метода декомпозиции может привести к потере ФЗ, например, при выделении из зависимости будут получены отношения и , ни одно из которых не будет содержать зависимость . В этом случае метод декомпозиции не работает.
Правильно (метод синтеза): ,
Использование описанного выше правила декомпозиции может быть осложнено присутствием избыточных ФЗ (ИФЗ).
ИФЗ -- зависимость, не заключающая в себе такой информации, которая не могла бы быть получена на основе других зависимостей, использованных при проектировании БД.
Поскольку ИФЗ не содержит уникальной информации, она может быть удалена из набора ФЗ. ИФЗ удаляется до начала проектирования (т.е. декомпозиции).
Возникновение ИФЗ связано с:
наличием транзитивных зависимостей;
добавлением.
Пример:
a) Исходный набор ФЗ После удаления ИФЗ
b) Эта форма избыточности имеет несколько видов:
Если , то является правильной, но избыточной;
Если , то избыточна.
Рассмотренные ПВ ФЗ из исходных ФЗ входят в состав так называемых аксиом вывода (АВ).
АВ -- правило, согласно которому, если отношение удовлетворяет определенным ФЗ, то оно должно удовлетворять и другим определенным ФЗ.
Рассмотрим 6 основных правил вывода (АВ).
Рефлексивность. АА,
Добавление (расширение)
а) если АВ, то А,СВ
б) если АВ, то А, С В,С ИФЗ
Транзитивность. Если АB и BC, то АС ИФЗ
4) Псевдотранзитивность. Если АB и B,СD, то А,СD ИФЗ
5) Объединение (аддитивность). Если АB и АС, то АВ,С
6) Декомпозиция (проективность). Если АВ,С, то АB и АС
Используя аксиомы вывода f1-f6 можно получить другие правила вывода для ФЗ. Например, с использованием аксиом f1 и f2 можно получить A,BB. Первые три аксиомы называются аксиомами Армстронга, оставшиеся три следуют из них. Использование полной системы аксиом позволяет вывести все функциональные зависимости, допустимые в множестве ФЗ. Пусть F - множество ФЗ для схемы отношений R. Множество ФЗ, которые логически следуют из F, называют замыканием F (F+). Если F=F+, то говорят, что F -- полное семейство зависимости. Вычисление F+ для F являются трудоемкой задачей, поскольку мощность F+ может быть велика даже при небольшой мощности F. Вычисление же X+ для данного множества атрибутов Х не представляет трудности. Х+-- это замыкание Х относительно F, если есть множество атрибутов А таких, что зависимость ХА может быть выведена из F по аксиомам f1,f2, f4.
2.1.3 Метод объектной связи
Отличается от метода декомпозиции тем, что ФЗ привлекаются не на начальном, а на конечном этапе проектирования.
Предположим, что проектируется БД, предназначенная для хранения информации о преподавателях и курсах, которые они читают. Двумя главными сущностями здесь являются преподаватель и курс. Они соотносятся с помощью связи "читает", что позволяет нам сказать "преподаватель читает курс". Связь "читает" может быть представлена двумя способами.
Метод ER-диаграмм в ER-экземплярах;
Метод ER-типов.
1) 2)
Необходимо различать понятия сущности и отношения. Сущность переходит в отношение путем выделения ее из ER-диаграмм. Отсюда различие между ключом сущности и ключом отношения, они не всегда совпадают. В процессе перехода сущность отношение ключ сущности может быть дополнен некоторым атрибутом и стать ключом отношения. В большинстве случаев для определения набора отношений используется диаграмма ER-типа (вторая схема).
Нетрудно подсчитать, что для двух объектов общее число возможных состояний . 4 типов соответствия; 2 класса принадлежности, 2 объекта.
Общий подход к проектированию
Связь "читает" -- бинарная, так как соединяет две сущности.
Строится диаграмма ER-типа, включающая в себя все сущности и связи;
Строится набор предварительных отношений с указанием предполагаемого первичного ключа для каждого отношения;
Составляется список всех атрибутов (тех из них, которые не были перечислены в ER-диаграмме в качестве ключей сущности), каждый из этих атрибутов приписывается одному из предварительных отношений с тем условием, чтобы эти отношения находились в НФБК. Для каждого отношения должны быть определены межатрибутные функциональные зависимости, с помощью которых проверяется соответствие отношений НФБК. Если полученные в итоге отношения не находятся в НФБК или если некоторым атрибутам не находятся логически обоснованных мест в предварительных отношениях, необходимо пересмотреть ER-диаграмму.
Предварительные отношения для бинарных связей с типом соответствия 1:1.
Перечень общих правил генерации отношений можно получить, опираясь на:
Тип соответствия;
Класс принадлежности;
как определяющие факторы.
Правило 1: Если степень бинарной связи равна 1:1 и класс принадлежности обеих сущностей обязательный, то требуется только одно отношение. Первичным ключом этого отношения может быть ключ любой из этих двух сущностей. В этом случае гарантируется однократное появление каждого значения ключа в любом экземпляре отношения.
Правило 2: Если степень бинарной связи равна 1:1 и класс одной из сущностей необязательный, то необходимо построение двух отношений, под каждую сущность необходимо выделение одного отношения. Ключ сущности, для которого класс принадлежности является необязательным, добавляется в качестве атрибута в отношение, выделенное для сущности с обязательным классом принадлежности.
В том случае, если класс принадлежности ни одной из сущностей не является необязательным, недостаточно использования и двух отношений, т.к. возникают проблемы с внесением ключа сущности в отношение, выделенное под другую сущность.
Правило 3: Если степень бинарной связи равна 1:1 и класс принадлежности ни одной из сущностей не является необязательным, то используется три отношения -- по одному для каждой сущности -- ключи которых служат в качестве первичных в соответствующих отношениях и одного для связи. Отношение, выделенное для связи, будет иметь по одному ключу сущности от каждой сущности. Читает (Пр#,К#, …)
Предварительные отношения для бинарных связей с типом соответствия 1:M.
Для них требуется два правила. Фактором, определяющим выбор и использование одного из этих правил, является класс принадлежности многосвязной сущности. Класс принадлежности односвязной сущности не влияет на конечный результат в обоих случаях.
|
Курс |
Пр# |
ФИО |
||
|
12 11 03 01 -- |
история политология физика математика -- |
3 3 4 5 6 |
Иванов Иванов Петров Сидоров Андреев |
Правило 4: Если степень бинарной связи равна 1:М и класс принадлежности М-связной сущности обязательный, то достаточно использовать два отношения: по одному на каждую сущность, при условии что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Ключ же односвязной сущности должен быть добавлен как атрибут в отношение, отводимое М-связной сущности.
То есть получим таблицы
|
К# |
Курс |
Пр# |
Пр# |
ФИО |
|
Если односвязная сущность вырождена в атрибут, то есть имеет в своем составе один атрибут, то возникает проблема.
Пример:
Товар хранится в ячейках на складе. В одной ячейке могут храниться товары разного рода, но каждый товар только в одной ячейке.
Ячейка вырождена.
Сотрудники занимают должность
Анализ примеров позволяет сделать вывод: если односвязная сущность представлена только ключом, то, в зависимости от класса принадлежности односвязной сущности, применяют разные правила:
а) Когда класс принадлежности односвязной сущности обязателен, то в "товар" добавляем "номер ячейки", получаем одно отношение.
б) Если класс принадлежности односвязной сущности необязателен, то имеем два отношения, так как "должность", которую никто не занимает, нужно хранить в БД.
Правило 5: Если степень бинарной связи равна 1:М и класс принадлежности М-связной сущности необязателен, то необходимо использовать три отношения: по одному на сущность и одно для связи. Связь должна иметь среди своих атрибутов ключ сущности от каждой сущности.
Предварительные отношения для бинарных связей с типом соответствия М:М.
Правило 6: Если степень бинарной связи равна М:М, то для хранения данных необходимо три отношения: по одному на сущность и одно для связи. Ключи сущности входят в связь. Если одна из сущностей вырождена, то -- два отношения (т.е. достаточно будет двух таблиц).
Предварительные отношения для многосторонних связей.
Правило 7: В случае трехсторонней связи необходимо использовать четыре отношения: по одному на сущность и одно для связи. Отношение, порождаемое связью, имеет в себе среди атрибутов ключи сущности от каждой сущности.
Если связь n-сторонняя, требуется N+1 отношений: N для сущностей и 1 для связи.
По правилу 6 имеем три отношения. Количество характеристика связи.
Имеем четыре отношения.
Использование ролей в ER-моделях.
Одних только сущностей и связей может оказаться недостаточно для моделирования. Одна из таких ситуаций возникает тогда, когда экземпляры некоторой сущности должны играть разные роли. Рассмотрим на примере.
Пример:
Пусть необходима база данных для хранения информации о персонале предприятия. Различают две категории служащих: мастеров и сборщиков, мастера получают фиксированный оклад, у сборщиков почасовая оплата. Построим ER-диаграмму.
Используем правило 4, получим отношение:
Мастер (М#, …)
Сборщик(C#, …, M#)
Проблема возникает при добавлении не ключевых атрибутов в предварительные отношения. Предположим, что такими не ключевыми атрибутами являются ФИО служащего, телефон рабочий, телефон домашний, адрес, ставка, оклад, разряд. Нет проблем при размещении следующих атрибутов к отношениям:
Мастер (М#, тел. рабочий, оклад)
Сборщик(C#, ставка, разряд, М#)
Не размещенными остались атрибуты: ФИО, домашний телефон, адрес. Для полноты их следовало бы поместить в оба отношения, однако, как это было в общем правиле проектирования, каждый ключевой атрибут следует размещать только в одном отношении. Можно, конечно, оставшиеся три атрибута преобразовать в шесть атрибутов. Однако это не будет удачным решением, поскольку может привести к следующей проблеме: предположим, необходимо найти номер домашнего телефона служащего X. Т.к. неизвестно: Х - мастер или сборщик, необходимо просмотреть оба отношения с целью нахождения именно Х. А если существуют два служащих с именами Х (мастер и сборщик), то может быть выбран неправильный номер телефона. Для решения этой проблемы необходимо завести отношение "служащие" (то есть построить таблицу служащих). Мастер и сборщик -- это те роли, которые они могут играть. Тогда ER-диаграмма имеет вид:
Шифр М#, C# и Сл# определены на одном домене.
Правило: исходная сущность служит источником генерации одного отношения. Ролевые элементы и связи, их соединяющие, порождают такое число отношений, которое определяется ранее описанными правилами. Причем каждая роль трактуется как обычная сущность.
Приведенный пример характеризуется
а) наличием связи между ролевыми объектами;
б) ролевые объекты не вырождены;
Особый случай возникает при наличии связи между вырожденными сущностями. Рассмотрим пример со спортивными командами, которые соревнуются друг с другом.
Получим два отношения:
Команда (K#, …)
Расписание (КХ#, КГ#, дата, счет)
Пример:
2.2 Организация СУБД
Понятие СУБД относится к набору средств ПО, необходимых для использования фактографических БД. Различают документальные и фактографические БД.
Документальные БД хранят совокупность произвольных текстовых документов.
Фактографические БД хранят множество сведений и фактов, хранящихся в информационной системе, удовлетворяющих фиксированной совокупности форматов.
СУБД -- это набор ПС, позволяющий:
Описать и манипулировать данными, для чего предназначены соответствующие языки: язык описания данных (ЯОД) и язык манипулирования данными (ЯМД). Термин ЯД означает либо оба, либо один из названных языков. ЯД может быть включен в универсальный язык, либо представлять собой оригинальное языковое средство. В первом случае, включаемый язык называется подъязыком данных, во втором автономным ЯД.
Поддерживать модели данных пользователя.
Обеспечить защиту и целостность данных. Защита -- это использование БД, пользователями имеющими на это право. Целостность -- поддержка согласованности данных.
Логически в современных СУБД можно выделить:
Внутренняя часть -- ядро СУБД (Data Base Engine -- DBE).
Компилятор языка БД (SQL).
Набор утилит.
Ядро отвечает за следующие процессы:
Управление данными во внешней памяти.
Управление буферами оперативной памяти.
Управление транзакциями.
Журнализация.
Выделяют следующие компоненты ядра (DBE):
Менеджер данных.
Менеджер буфера.
Менеджер транзакций.
Менеджер журнала.
Ядро СУБД обладает собственным интерфейсом, недоступным пользователю напрямую. Этот интерфейс используется программами, производимыми компилятором SQL и утилитами БД.
При использовании архитектуры "клиент-сервер" ядро является основной составляющей сервера.
Основная функция компилятора -- компиляция операторов языка БД в некоторую программу. Основной проблемой реляционных СУБД является то, что языки этих систем (SQL) являются непроцедурными.
2.2.1 Требования к современной СУБД
Традиционные файловые системы характеризуются тесной связью между физическими данными и прикладной программой. В ней отсутствуют практически все средства, предлагаемые СУБД.
Перечислим основные проблемы, возникающие в файловых системах:
Зависимость данных;
Жесткость и статичность;
Дублирование данных;
Отсутствие интеграции;
Невозможность обработки нетипичных запросов.
Современные СУБД разрабатываются с целью устранения этих недостатков.
Основные требования:
Независимость данных. Одна из самых важных задач при разработке БД -- спроектировать ее так, чтобы изменение БД можно было выполнить без модификации прикладных программ. Для реализации этого требования структура БД должна отвечать требованиям физической и логической независимости данных. Физическая независимость данных -- когда в файловой организации данных и в аппаратных средствах вносятся изменения, они должны быть отражены в ПО БД (т.е. в СУБД), но не должны затрагивать прикладные программы. Логическая независимость данных -- представление данных в прикладной программе должно быть защищено от изменения:
в глобальной логической структуре;
в требованиях данных других прикладных программ.
Примеры возможных изменений:
а) модификация старых прикладных программ;
б) добавление новых прикладных программ, использующих новые типы данных;
в) добавление новых полей и создание новых связей.
Для достижения такой независимости необходимо отделить представление данных в каждой прикладной программе от общего логического представления и обеспечить возможность добавления новых полей в запись без перезаписи тех прикладных программ, которые используют эту запись. Тогда перечисленные изменения приведут к модификации общего логического представления и не коснутся прикладной программы.
Должны существовать три отдельных представления организации БД:
физическое;
общелогическое (концептуальная модель);
представление данных в прикладных программах.
Итак, при логической независимости данных изменения ни в СУБД, ни в других прикладных программах не должны привести, в идеале, к изменению программы пользователя.
Универсальность. СУБД должна поддерживать разные модели данных.
Совместимость. Сохранение работоспособности при развитии программного и аппаратного обеспечения.
Минимальная избыточность данных.
Целостность данных.
а) физическая -- защита данных от физических разрушений. Обеспечивается средствами ведения журнального файла, в котором регистрируются все изменения БД с некоторого момента времени. На момент начала ведения журнального файла создается копия БД.
б) логическая -- предупреждает неверное использование данных. Обеспечивается механизмом управления доступом к данным. Ограничение доступа ко всей БД, доступ не ко всей записи, а только к ее части, заданной областью допустимых значений.
в) семантическая -- поддерживает осмысленное сочетание разных данных.
Защита данных от несанкционированного доступа.
а) конфиденциальность --защита от несанкционированного получения данных;
б) целостность -- защита от несанкционированного изменения данных;
в) доступность -- защита от несанкционированного удержания данных.
Обеспечение коллективного доступа к данным. Поскольку данные интегрированы, возникает проблема синхронизации параллельного доступа к одним и тем же данным многих пользователей. Обычно проблема возникает при записи. Также проблема возникает, когда процедура обновления завершается аварийно. В этом случае до разблокировки необходимо выполнить откат, или восстановление назад. При откате будут уничтожены все изменения БД, инициированные процедурой обновления.
СУБД должна поддерживать как централизованные, так и распределенные БД.
2.2.2 Архитектура СУБД
Существует несколько уровней представления данных:
Описание конкретного конечного пользователя, имеющего локальное описание;
Общее логическое описание, интегрирующее описание локальных пользователей;
Описание физической организации БД.
Описание модели на каком-либо языке называется схемой. В соответствии с уровнями представления различают:
Подсхема, или внешняя схема -- представление локального пользователя;
Концептуальная схема, или модель описания логической структуры БД на языке СУБД.
Физическая, или внутренняя схема.
Указанные виды схем связывают больше с этапом эксплуатации БД, когда БД уже спроектирована, и общая логическая схема нашла свое отражение в конкретной СУБД.
На этапе проектирования можно выделить логическое пользовательское представление и информационную схему предметной области.
Все эти разновидности уровней описания принято связывать с понятием архитектура СУБД.
Описание предметной области, выполненное без ориентации на используемые в дальнейшем программные и технические средства, называется инфологической моделью предметной области, а сам этап проектирования -- инфологическим проектированием. Концептуальная модель БД является моделью логического уровня, то есть обрабатывает логические связи между элементами данных безотносительно к их содержанию и среде хранения.
Эта модель строится в соответствии терминам той конкретной СУБД, в среде которой проектируется БД. Этот этап называется даталогическим проектированием.
Описание физической структуры БД называется схемой хранения. Этот этап называется физическим проектированием. На этом этапе могут выполняться следующие работы:
Выбор типа носителя;
Способ организации данных;
Метод доступа;
Определение размера физического блока;
Выбор методов сжатия или отказ от них;
Проблема утилизации и т.д.
В большинстве настольных СУБД этот этап проектирования скрыт от пользователя.
Описание логической структуры БД с точки зрения конкретного пользователя называется подсхемой. Это внешняя модель БД. Если СУБД поддерживает схему, схему хранения и подсхему, то она является СУБД с трехуровневой архитектурой. Если СУБД поддерживает уровень подсхем, то перед проектировщиком возникает задача их определения. Это можно рассматривать как еще один этап проектирования. Если определена подсхема, то пользователь имеет доступ только к тем данным, которые отражены в соответствующей подсхеме, что является одним из способов защиты информации от несанкционированного доступа к данным. В подсхеме могут также задаваться допустимые режимы обработки, что служит дополнительным механизмом защиты информации от разрушения.
В тех случаях, когда СУБД не поддерживает подсхемы, перечисленные функции могут выполнять другие компоненты системы. Близким к понятию подсхем является понятие "представление".
2.2.3 Работа СУБД
На рисунке представлена последовательность основных действий, реализуемых СУБД в процессе считывания записи для прикладной программы.
Прикладная программа А выдает запрос СУБД на чтение записи.
СУБД получает в распоряжение подсхему, исполняемую программой А, и осуществляет в ней поиск описания данных, на которые выдан запрос.
СУБД получает в распоряжение схему (глобальное логическое описание данных) и с ее помощью определяет необходимый тип логических данных.
СУБД просматривает описание физической организации БД и определяет, какую физическую запись требуется считать.
СУБД выдает операционной системе команду чтения требуемой записи.
Операционная система взаимодействует с физической памятью, в которой хранятся данные.
Запрошенные данные передаются из памяти в системный буфер.
СУБД осуществляет сравнение схемы и подсхемы, выделяет ту логическую запись, которая запрошена прикладной программой. Любое преобразование данных, необходимость которого возникает из-за различий в описании одних и тех же данных в схеме и подсхеме, выполняется СУБД.
СУБД передает данные из системного буфера в рабочую область прикладной программы А.
СУБД передает прикладной программе информацию о результатах выполнения различных процедур по обслуживанию ее запросов. Эта информация содержит также сведения о возможных ошибках.
Прикладная программа обрабатывает данные, помещенные в рабочую область.
2.3 Организация данных
2.3.1 Физическая организация данных
Проблема физической организации данных: каким образом можно представить структуры данных в памяти компьютера в виде последовательной цепи?
Аспекты проблемы:
Как можно найти необходимую запись среди множества данных? Группа битов, которую можно прочитать с помощью одной машинной инструкции, называется одной физической записью. Программы идентифицируют логическую запись с помощью ключа.
Ключ машинный адрес
Переход от ключа к адресу определяет сущность способа адресации, которые будут рассмотрены ниже.
Каким образом организовать данные, чтобы поиск был эффективным, а выборку записей можно было бы осуществлять по нескольким ключам?
Каким образом древовидные сетевые структуры можно представить в виде последовательности битов?
Как добавить новую запись к данным, уничтожить старые записи, не нарушая структуры адресации и поиска, а также структуру данных?
Ключ БД -- RID (Record IDentificator)
Каждой записи СУБД присваивается внутренний идентификатор. Ключ БД не следует приравнивать ключу записи. Если значение ключа записей задается пользователем, то RID устанавливается системой при размещении.
Пример:
RID состоит из номера страницы и номера записи на странице;
Последовательный номер записи в файле.
В некоторых системах пользователь не знает RID, в других -- он доступен пользователю, который может его использовать.
При описании типа записи (имя таблицы) администратором БД определяется область хранения. ОХ -- участок памяти, т.е. совокупность страниц, внутри которого могут размещаться записи описываемого типа. Вне области хранения записи размещаться не могут.
В некоторых системах для любой записи используется своя область хранения, в других они могут пересекаться, и тогда на одной странице могут оказаться записи разных типов.
Характеристики файла данных: Параметры блокирования страниц
Формат и длина страницы
Запись может быть сегментирована, если она не умещается на одной странице.
Файл БД:
Как по первичному ключу определить месторасположение записи с данным ключом?
Последовательное сканирование файла -- сканируется файл с проверкой ключа каждой записи. Эффективен только для файлов с последовательным доступом. Записи должны быть упорядочены по ключу.
Блочный поиск -- записи упорядочиваются по ключу. И при сканировании файла можно рассматривать не каждую запись, а каждую сотую в последовательности возрастающих ключей. Затем область поиска сужается.
Двоичный поиск -- рассматривается запись в середине области, в которой выполняется поиск и ее запись сравнивается с поисковым ключом. Делится пополам.
Индекс на последовательный файл -- последовательное сканирование файла для нахождения записи требует много времени, если оно выполняется над всем файлом. Но сканирование можно использовать для небольшой области, которая представляет весь файл. Пусть файл упорядочен по ключу. Для адресации к такому упорядоченному файлу используется таблица, называемая индексом.
Индекс на произвольные файлы -- записи располагаются в произвольной последовательности, как правило, в порядке ввода в БД. Непоследовательный файл можно индексировать точно также, как и последовательный. Но для этого требуется значительно больший по размеру индекс, т.к. он должен содержать по одному элементу для каждой записи файла, а не для блока записей. Кроме того, в нем должны содержаться полные абсолютные адреса.
Адресация с помощью ключа, эквивалентного адресу. Известны много методов преобразования ключа непосредственно в адрес в файле. Когда такое преобразование возможно, оно обеспечивает самую быструю адресацию. Например, в некоторых банковских системах номера счетов изменялись так, чтобы номер счета или его часть являлись бы адресом записи в БД.
Алгоритм преобразования ключа в адрес дает почти ту же скорость, что и предыдущий. Но характеризуется неэффективным использованием памяти. Поскольку ключи преобразуются в непрерывное множество адресов, в файле остаются свободные участки.
Хеширование. При запоминании новой записи специальная программа ставит в соответствие значению первичного ключа номер страницы, куда следует поместить запись. Таким образом, перемешиваются по страницам все записи. Записи, для которых хеширование выдает одинаковые страницы, называются синонимами. Синонимы объединяются в связанный список, начало которого находится в заголовке таблицы. Если при заполнении очередного синонима для него не хватило места на одной странице, он размещается на другой странице, но включается в цепь синонимов той области, куда был хеширован. При извлечении записи по первичному ключу СУБД подключает программу хеширования, вычисляет номер страницы, а затем просматривает цепь синонимов на этой странице до нахождения нужной записи.
2.3.2 Организация индексных таблиц
Индекс можно определять как таблицу, воспринимающую на входе информацию о некоторых значениях атрибутов и выдающую на выходе информацию, соответствующую быстрому поиску записей, которые имеют заданное значение атрибутов.
Индексная таблица должна быть упорядочена по входному индексу.
Следует различать индексирование по первичному ключу и вторичное индексирование.
Первичное индексирование
СУБД, размещая записи на странице данных, формирует специальные индексные таблицы. Они используются для нахождения адреса записи по значению первичного ключа. При этом СУБД производит поиск записи не в файле, а в индексе. Если записи файла упорядочены по ключу, индекс обычно содержит не ссылки на каждую запись, а ссылки на блоки записи, внутри которых можно выполнять поиск или сканирование.
Рассмотрим один из известных механизмов индексирования. Пусть записи имеют ключи со значениями из натурального ряда. Перед загрузкой записи должны быть упорядочены по значению ключей.
Особенности первичного индексирования:
Ключ индексирования должен иметь уникальное неизменное значение;
Первоначальная загрузка должна выполняться обязательно с предварительной сортировкой;
Формирование индексной таблицы происходит одновременно с загрузкой записей файлов, а значение ключей индексирования влияют на размещение записей в памяти.
Вторичное индексирование
При обработке БД возникает потребность извлечения записи по значению данных, отличных от первичного ключа, например, извлечь данные из записи о студентах данной специальности или по специальности -- номер группы. Последовательный просмотр большого числа записей может оказаться неэффективным. Другой вариант состоит в использовании вторичного индексирования.
Вторичные ключи могут идентифицировать записи неединственным образом. Одному вторичному ключу могут соответствовать несколько записей
КБД -- ключ БД
Особенности вторичного индексирования:
Вторичные ключи могут иметь неуникальное значение. Допускается изменение значений вторичных ключей. При этом системой автоматически будут корректироваться соответствующие таблицы.
Вторичное индексирование служит только для выборки данных и никак не используется при размещении данных в памяти.
Таблицы вторичного индексирования можно создавать не только при первоначальной загрузке, но и в любое другое время.
Организация индексных таблиц должна обеспечивать быстрое нахождение адреса записи по значению ключа. Один из механизмов индексирования нам уже известен, это иерархия индексных таблиц с последовательным просмотром внутри таблицы. Этот механизм работает только если записи перед загрузкой накапливаются и упорядочиваются. Если же загрузка БД происходит в реальном времени, то этот механизм малоэффективен. Рассмотрим другие механизмы индексирования.
Бинарное деление
Индексная таблица при этом механизме индексирования состоит из множества записей, связанных адресными ссылками в иерархическую структуру. Такие записи называют индексными.
Каждая индексная запись (ИЗ) содержит
Значение ключа записи;
Адрес этой записи (ключ БД);
Адресная ссылка на ИЗ с ключом меньше данного;
Адресная ссылка на ИЗ с ключом больше данного.
При этом механизму не требуется, чтобы записи предварительно накапливались и упорядочивались. Каждой записи БД соответствует одна ИЗ. Первая ИЗ становится корневой.
Пример:
|
# записи |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
|
|
Ключ записи |
12 |
8 |
4 |
9 |
6 |
13 |
14 |
16 |
100 |
10 |
25 |
31 |
Поиск записи по значению ключа выполняется по тому же алгоритму, начиная с корня БД. Механизм основан на известном дихотомическом поиске. Наряду с достоинствами, бинарные деревья имеют значительные недостатки. В нашем примере для извлечения записи с ключом записи, равным 31, требуется 7 шагов, а для записи, с КЗ=6 -- 4 шага, хотя обе записи конечны. Такое дерево называется несбалансированным.
Сбалансированные деревья -- деревья, в которых все конечные вершины равноудалены от корня. Если бинарное дерево растет вниз и корень неизменен, то В-дерево растет вверх и корень меняется.
В-дерево n-ого порядка должно удовлетворять следующим условиям:
Любая вершина может содержать n адресных ссылок и n-1 ключей. Ссылка влево от ключа обеспечивает переход к вершинам дерева с меньшими значениями ключа, вправо -- с большими.
Любая неконечная вершина может иметь не менее n/2 подчиненных вершин.
Если неконечные вершины содержат k ключей, то им подчинена k+1 вершина на следующем уровне иерархии.
Все конечные вершины В-дерева расположены на одном уровне.
Алгоритм формирования В-дерева предполагает первоначальное заполнение корня до тех пор, пока не будут сформированы все ее n-1 ключей. Затем при появлении очередной записи выделяется новая корневая вершина и несколько подчиненных ей вершин. При запоминании нового ключа поиск места для него начинается с корня В-дерева. При этом используется алгоритм, рассмотренный для бинарного дерева.
Пример:
Пусть сгружается та же последовательность записей с формированием бинарного дерева с n=3. Тогда каждая запись такого дерева рассчитана на хранение 2-х ключей и 3-х ссылок. Первоначально корневая вершина содержит только ключ 12.
Затем он сдвигается вправо, уступая место ключу 8, так как внутри записи ключи расположены в порядке возрастания значений.
Далее, поскольку для ключа 4 нет записи в корневой записи, происходит ее деление. Из трех ключей (4, 8, 12) выбирается средний ключ (8), чтобы ключи 4 и 12 попали в две подчиненные записи.
При этом будет выполнено ограничение 2) и 3). Это общее правило для деревьев 3-го порядка.
В итоге получим следующее дерево:
Связанные списки
В сетевых иерархических моделях данных связь с данными
поддерживается групповыми отношениями. Наиболее распространенный способ реализации группового отношения -- построение связанных списков.
Последняя подчиненная запись содержит либо ссылку на владельца, либо признак конца цепи (замкнутый или разомкнутый список). Рассмотренный тип ссылок называется ссылками на следующий. В цепном связанном списке могут использоваться и другие типы ссылок:
ссылка на владельца обеспечивает движение по групповому отношению вверх;
ссылка на предыдущий обеспечивает просмотр в обратном направлении и повышает эффективность процедур удаления записей из группового отношения. Ссылка на предыдущий формируется у всех участников списка, включая запись владельца. Владелец при этом будет содержать кроме ссылки на первую подчиненную запись еще и ссылку на последнюю.
Пусть, например, необходимо удалить В2. Удаление будет корректным, если В1 будет указывать на В3. Для этого необходимо сделать шаг назад, для чего и нужна ссылка на предыдущий узел.
Существует несколько видов отображения групповых отношений на физическую память. Чаще всего -- левосторонний обход структуры дерева, за последней записью первого дерева размещается корень следующего и т.д.
|
Стр.1 |
А1 |
В1 |
М1 |
М2 |
В2 |
|
|
Стр.2 |
В3 |
М3 |
М4 |
М5 |
Н1 |
2.4 Обновление и восстановление данных
При динамической реорганизации страниц записи плотно размещаются в начале каждой страницы, а в конце расположен свободный участок. Тогда адрес начала свободного участка хранится в начале таблицы.
При удалении некоторой записи таблица сжимается и увеличивается длина свободного участка. Для учета свободных участков на странице СУБД поддерживает инвентарные страницы. Одна инвентарная страница создается для группы страниц данных и содержит сведения о наличии на них свободных участков памяти.
Запоминание новых записей
При запоминании СУБД ищет место для записи в области хранения. Поиск ведется сначала через инвентарные страницы, а затем -- на страницах данных. Если для учета свободных участков используется цепи участков, то СУБД выбирает первый свободный участок, пригодный по длине. Если длина записи меньше длины свободного участка, то участок оформляется в виде нового свободного участка. В результате может образоваться несколько небольших свободных участков, не позволяющих запомнить новую запись.
При динамической реорганизации страниц такого случиться не может, так как на каждой странице поддерживается один свободный участок. После запоминания записи СУБД корректирует содержимое соответствующей инвентарной страницы.
Корректировка
Если элементы данных имеют фиксированную длину, то обновленные значения помещаются на место прежних. Если система допускает переменную длину, то обновленная запись может иметь длину отличную от прежней. В этом случае либо реорганизуется страница, либо перемещается запись на другой участок памяти.
Транзакция
Восстановление данных в СУБД означает возвращение БД в согласованное, непротиворечивое состояние, если какой-нибудь сбой сделал текущее состояние противоречивым. Принцип, на котором строится такое восстановление, это избыточность, которая образуется на физическом уровне. Если любая часть информации содержащейся в БД, может быть восстановлена из другой (хранимой в БД или извне), то такая БД восстановимая. Проблемы восстановления и параллелизма являются аспектами одной проблемы -- проблемы транзакции.
Транзакция -- это последовательность операций над БД, рассматриваемая СУБД как единое целое.
Особенности транзакции:
Всегда связана с изменениями в БД, вызываемых операциями INSERT, DELETE, ACCEPT в SQL;
Транзакция -- логически связанная последовательность одной или нескольких таких операций, которые преобразуют одно непротиворечивое состояние БД в другое, но не гарантируют этого в промежуточные моменты времени.
Пример:
Пусть мы хотим изменить значение первичного ключа какого-либо кортежа. Для этого используется команда UPDATE. По ней за один раз можно обновить только одну таблицу. Поэтому одной операцией UPDATE не обойтись, так как кортеж -- это этап в других отношениях. В данном примере мы сталкиваемся с проблемой целостности по ссылкам. БД становится противоречивой после выполнения первой команды UPDATE. Тогда транзакция будет включать в себя столько операций UPDATE, сколько раз этот кортеж входит в другие отношения.
Что будет, если внутри транзакции будет аварийный отказ? Все зависит от того, поддерживает ли система обработку транзакций. Система, обрабатывающая транзакции, гарантирует, что если в транзакцию входит обновление базы данных, а затем произошла ошибка (до того, как транзакция достигла нормального завершения), то эти обновления будут аннулированы.
Таким образом, возможны два исхода выполнения транзакции:
Транзакция полностью исполняется;
Транзакция полностью аннулируется.
С точки зрения конечного пользователя транзакция кажется атомарной -- ее обслуживают системные компоненты -- монитор (диспетчер) транзакций (МТ). МТ не является частью СУБД, наоборот, СУБД подчиняется МТ. МТ определяет две команды:
COMMIT -- фиксация;
ROLLBACK -- откат.
В зависимости от типа МТ они могут выглядеть по-разному.
Точка синхронизации (ТС) представляет собой граничную точку между двумя последовательными транзакциями. ТС устанавливается при инициализации программы и при выполнении команд МТ:
COMMIT -- сообщает об успешной транзакции и устанавливает ТС. Все обновления, сделанные транзакцией, фиксируются. Снимаются все блокировки записей, все открытые курсоры закрываются.
ROLLBACK -- сообщает о неудачном завершении транзакции и устанавливает ТС. Все обновления программы (после установки последней ТС) аннулируются. Снимаются все блокировки записей, все открытые курсоры закрываются.
Восстановление транзакции
Производится в ситуациях:
Индивидуальный откат транзакции;
явное завершение оператором ROLLBACK,
откат производится самой системой (выбор транзакции как "жертвы" в синхронизационном тупике);
Восстановление после внезапной потери содержимого ОЗУ (мягкий сбой);
Восстановление после поломки основного внешнего носителя (жесткий сбой).
Во всех трех случаях основа восстановления -- избыточное хранение данных. Они хранятся в журнале, содержащем последовательность записей об изменении БД. Журнализация изменений часто связана не только с управлением транзакциями, но и с буферизацией страниц БД в оперативной памяти.
Если бы запись об изменении БД сразу записывалась во внешнюю память, это привело бы к замедлению работы системы. Поэтому записи журнала тоже буферизируются.
Существуют два вида буферов:
Буфер журнала;
Буфер страниц БД.
Оба буфера всегда восстанавливаются во внешнюю память. Проблема состоит в выработке восстановления буфера во внешнюю память. Основным принципом такого восстановления является то, что запись об изменении объекта БД должна попадать во внешнюю память раньше, чем измененный объект помещается во внешнюю память. Такой протокол называется "пиши сначала в журнал"
Индивидуальный откат транзакции
Выбирается очередная запись из списка данной транзакции;
Выбирается противоположная по смыслу операция;
Любая из этих обратных операций также журнализируется;
При успешном завершении отката заносится в журнал запись о конце транзакции.
Восстановление после мягкого сбоя
Страницы БД буферизируются в ОЗУ и восстанавливаются независимо;
Несмотря на применение WAL после мягкого сбоя набор атрибутов БД во внешней памяти может оказаться несогласованным, т.е. часть страницы во внешней памяти соответствует БД до изменения, часть -- после изменения.
Состояние внешней памяти БД называется физически согласованным, если наборы всех страниц согласованны, т.е. соответствуют состоянию объекта либо до, либо после изменений.
Будем считать, что в журнале отмечаются точки согласованности БД, т.е. моменты времени, в которые во внешней памяти создаются согласованные результаты операций, завершенных до соответствующего момента времени, и отсутствуют результаты операций, которые не завершились, а буфер журнала вытолкнут во внешнюю память. Тогда к моменту мягкого сбоя будут следующие состояния транзакций:
Пусть удалось восстановить внешнюю память БД к согласованному состоянию и времени tфс, тогда для:
T1 -- никаких действий не производить.
T2 -- нужно повторно выполнить оставшуюся часть операций, так как во внешней памяти полностью отсутствуют следы операций, которые выполнялись транзакцией после времени tфс.
Это приведет к согласованному состоянию БД, так как транзакция Т2 успешно завершилась до момента мягкого сбоя и в журнале содержатся все действия (REDO).
T3 -- выполняется в обратном направлении первая часть операций (UNDO).
Во внешней памяти БД полностью отсутствуют результаты операций транзакций Т3, которые были выполнены после tфс. С другой стороны, во внешней памяти существуют результаты операций Т3, которые были выполнены до tфс.
Т4 -- выполняются повторно полностью все операции (REDO).
Т5 -- никакие действия не предпринимаются.
Во внешней памяти БД полностью отсутствуют результаты операций транзакции Т5.
Восстановление после жесткого сбоя
При восстановлении последнего состояния БД после жесткого сбоя журналы и данные явно недостаточны. Основой восстановления в этом случае является журнал и архивные копии БД. Восстановление начинается с обратного копирования БД из архивной копии. Затем для всех закончившихся транзакций выполняется REDO, т.е. операции повторно выполняются в прямом смысле. Более точно происходит следующее:
По журналу в прямом направлении выполняются все операции;
Для транзакций, которые не закончились к моменту сбоя, выполняется откат.
Так как жесткий сбой не сопровождается утратой буферов ОЗУ, можно восстановить БД до такого уровня, что даже можно выполнить незавершенные транзакции.
Хотя к ведению журнала предъявляются особые требования по части надежности, возможна его утрата. Тогда единственным способ восстановления БД является возврат к архивной копии. В этом случае не удается получить последнее согласованное состояние БД.
2.5 БД в сетях
По характеру организации хранения данных и обращения к ним различают персональные (локальные), централизованные и распределенные базы данных.
Персональные -- все части СУБД размещаются на компьютере пользователя локальной БД. Если к одной БД обращаются несколько пользователей одновременно, то каждый пользователь должен иметь свою копию. Этот вариант в корпоративной работе практически не встречается, т.к. в нем чрезвычайно трудно синхронизировать содержимое нескольких копий БД. Это проблема согласования (репликации) БД.
Централизованные -- такие БД, которые хранятся на одном компьютере, находящемся в узле сети, с помощью которой различные подразделения получают доступ к данным. Централизованные базы данных обычно организуются в рамках локальной вычислительной сети.
Распределенные -- такие БД, в которых данные распространяются по сети.
Приведенные понятия следует отличать от понятия распределенной обработки данных, которая может быть организована и при централизованном хранении БД. Пусть большая БД расположена на мощном компьютере. Можно организовать доступ к этой БД из других компьютеров, подключенных к сети. При этом выборка и предварительная обработка данных будет выполняться мощной машиной, а окончательная обработка и представление данных -- менее мощным ПК пользователя-клиента.
Подобные документы
Понятие базы данных, её структура. Общие принципы хранения информации. Краткая характеристика особенностей иерархической, сетевой и реляционной модели организации данных. Structured Query Language: понятие, состав. Составление таблиц в Microsoft Access.
лекция [202,8 K], добавлен 25.06.2013Основные этапы проектирования базы данных. Access как система управления базами данных (СУБД), ее предназначение, отличительные возможности. Работа с таблицами, их создание и редактирование. Порядок создания запросов. Способы защиты баз данных.
лабораторная работа [3,1 M], добавлен 18.08.2009Базы данных с двумерными файлами и реляционные системы управления базами данных (СУБД). Создание базы данных и обработка запросов к ним с помощью СУБД. Основные типы баз данных. Базовые понятия реляционных баз данных. Фундаментальные свойства отношений.
реферат [57,1 K], добавлен 20.12.2010Система управления базой данных (СУБД), централизованное обеспечение безопасности и целостности данных, защита от несанкционированного доступа. Построение концептуальной и реляционной моделей. Процесс нормализации. Проектирование базы данных в ACCESS.
курсовая работа [1,8 M], добавлен 29.10.2008Понятие и сущность базы данных, их классификация и характеристика. Системы управления базами данных. СУБД структуры "сервер-клиент", его суть. Microsoft Access - функционально полная реляционная СУБД. Предназначение СУБД Access, и описание ее работы.
реферат [44,3 K], добавлен 27.02.2009Основные понятия, используемые в теории управления базами данных. Характеристика объектов MS Access. Построение базы данных, содержащей информацию об учебном процессе текущего семестра. Свойства полей таблицы, работа с записями, импортирование данных.
лабораторная работа [46,0 K], добавлен 23.12.2010Общая характеристика системы управления базами данных MySQL, ее основные особенности и возможности, касающиеся обеспечения целостности данных. Реализация ограничений семантической и ссылочной целостности в СУБД MySQL на примере фрагмента ИС "Салон магии".
курсовая работа [981,0 K], добавлен 14.10.2012Современные системы управления базами данных (СУБД). Анализ иерархической модели данных. Реляционная модель данных. Постреляционная модель данных как расширенная реляционная модель, снимающая ограничение неделимости данных, хранящихся в записях таблиц.
научная работа [871,7 K], добавлен 08.06.2010Преимущества и недостатки иерархической модели данных. Целостная часть реляционной модели данных. Базовые требования целостности сущностей и по ссылкам. Ограничения целостности сущности и по ссылкам. Аксиомы Армстронга, аномалии обновления и их виды.
контрольная работа [262,3 K], добавлен 05.02.2011Исследование процесса разработки базы данных, позволяющей определять состояние кафедр и факультетов Дагестанского государственного технического университета. Характеристика иерархической, сетевой, реляционной, даталогической и физической моделей данных.
курсовая работа [156,7 K], добавлен 08.02.2012
