Агентство недвижимости

 

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

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

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

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

2.1.2 Логическая структура реляционной  базы данных

Логическая структура  реляционной базы данных в Access является адекватным отображением полученной информационно-логической модели, не требующим дополнительных преобразований. Каждый информационный объект модели данных отображается соответствующей реляционной таблицей. Структура реляционной таблицы определяется реквизитным составом соответствующего информационного объекта, где каждый столбец (поле) соответствует одному из реквизитов объекта. Ключевые реквизиты объекта образуют уникальный ключ реляционной таблицы. Для каждого столбца задается формат и размер данных. Строки (записи) таблицы соответствуют экземплярам объекта и формируются при загрузке таблицы.

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

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

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

 

 

Рис.2.2. Логическая структура реляционной базы данных предметной области “Больница”

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

2.1.3 Сравнительные характеристики  моделей БД

Таблица 2.1

Вид модели	Достоинства	Недостатки
Иерархическая	- простота понимания; - простота оценки операционных  характеристик;	- отношения М:М могут быть реализованы только искусственно; - могут быть избыточные  данные; - усложняются операции  включения и удаления; - удаление исходных  объектов ведет к удалению  порожденных объектов; - процедурный характер манипулирования данными; - доступ к любому  порожденному узлу возможен только  через корневой узел; - сильная зависимость  логической и

 

Продолжение таблицы 2.1

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

 

2.2 Требования к эксплуатационным  характеристикам

Эксплуатационные характеристики:

1. Целостность – свойство баз данных, при котором данные удовлетворяют некоторым ограничениям и сохраняют это качество при любых изменениях.
2. Согласованность – свойство базы данных выдавать одинаковые ответы на одновременно заданные одинаковые запросы.
3. Восстанавливаемость – возможность восстановления целостности базы данных после любого сбоя.
4. Безопасность – защита данных от преднамеренного или непреднамеренного доступа, модификации или разрушения.
5. Эффективность – используемые вычислительные ресурсы и время отклика.

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

Реляционная модель данных (РМД) — логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка.

На реляционной модели данных строятся реляционные базы данных.

Реляционная модель данных включает следующие компоненты:

Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.

Аспект (составляющая) целостности  — отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.

Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное  исчисление).

Кроме того, в состав реляционной модели данных включают теорию нормализации.

Термин «реляционный»  означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину  «отношение» часто встречается  слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина «таблица» вместо термина «отношение» нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с «плоскими», или «двумерными» таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни «плоскими», ни «неплоскими».

Для лучшего понимания  РМД следует отметить три важных обстоятельства:

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

2.3.1 основные понятия

Атомарные данные – наименьшая единица данных, не разложимая с точки зрения модели.

Домен – множество атомарных значений одного и того же типа.

Атрибут – некоторые подмножество домена, имеющие уникальное имя.

Отношение – некоторое подмножество декартова произведения доменов, имеющее уникальное имя.

Реляционная модель – множество отношений.

Кортеж – множество значений атрибутов отношения по одному значению на атрибут.

2.3.2. Целостность реляционной модели

Целостность данных - это механизм поддержания соответствия базы данных предметной области. В реляционной модели данных определены два базовых требования обеспечения целостности:

• целостность ссылок
• целостность сущностей.

 Целостность сущностей.

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

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

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

Целостность ссылок

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

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

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

Пусть, например, даны отношения Пациент (Код больного) и Личные данные пациента (Код больного), в которых хранятся сведения о пациентах, которые лежат в данной больнице. Отношение Пациенты в данной паре является родительским, поэтому его первичный ключ "Код больного" присутствует в дочернем отношении Личные данные пациента.