Технология проектирования и администрирования баз данных и систем данных-Конспект

Рис. 4.16

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

Рис. 4.17

Область – это поименованная часть базы данных, в которой могут содержаться экземпляры записей и наборов или частей наборов. Каждая область может обладать собственными уникальными физическими характеристиками Области могут обрабатываться как по отдельности, так и вместе с другими областями.

Рассмотрим основные компоненты сетевой модели данных: записи и наборы.

В сетевой модели данных объекты предметной области объединяются в «сеть». Графически сетевая модель представляется с помощью прямоугольников и стрелок. Каждый тип записи может содержать нуль, один или несколько атрибутов (употребляются также термины «элемент данных» и «поле»).

Поясним различие между типом и экземпляром записи. ПАЦИЕНТ является типом записи, а строка символов «I 111 Джон Уайт 15 Нью-Стрит, Нью-Йорк, Н.-Й.» – экземпляром типа записи ПАЦИЕНТ (рис. 4.18 и 4.19). Таким образом, в базе данных может иметься один или несколько экземпляров записи некоторого типа.

Рис. 4.18

В наборе ПАЦИЕНТ-ПЕРЕНЕС-ОПЕРАЦИЮ владельцем является запись ПАЦИЕНТ, а членом – запись ОПЕРАЦИЯ.

Рис. 4.19

Экземпляр набора ПАЦИЕНТ ПЕРЕНЕС ОПЕРАЦИЮ содержит один экземпляр записи владельца и два экземпляра записи члена. Набор реализован в виде кольцевой структуры. Имеются и другие способы его реализации.

Направленные стрелки соединяют два или более типов записей и служат для изображения типов набора. Тип записи, из которого исходит стрелка, называется владельцем набора, а тип записи, к которому направлена стрелка – членом набора. Стрелка, направленная от владельца набора к его члену, обозначает тип набора. Тип набора представляет логическую взаимосвязь «один ко многим» между владельцем и членом набора (рис 4.18). При этом не предполагается, что экземпляры членов набора должны располагаться вблизи экземпляра владельца набора в физической памяти, хотя это и возможно.

•Набор – это поименованная совокупность связанных записей.

•В каждом экземпляре набора имеется только один экземпляр владельца.

•Экземпляр набора может содержать нуль, один или несколько записей-членов.

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

•Экземпляр набора существует после запоминания записи-владельца. Каждому типу набора присваивается имя, что позволяет одной и той же

паре типов объектов участвовать в нескольких взаимосвязях.

Необходимо различать тип и экземпляр набора. В примере на рис. 4.19 тип набора – ПАЦИЕНТ ПЕРЕНЕС ОПЕРАЦИЮ. Экземпляр этого типа набора представлен экземпляром типа записи-владельца ПАЦИЕНТ «I 111 Джон Уайт 15 Нью-стрит, Нью-Йорк, Н-Й» и экземплярами типа записи-члена «01.01.77, Удаление камней из желчного пузыря, Пенициллин, Сыпь» и «12.06.77, Удаление камней из почек, — ,—». Таким образом, экземпляр типа набора состоит из одного экземпляра типа записи-владельца и нуля или более экземпляров типа записи-члена данного типа набора. Между экземпляром типа записи-владельца и экземплярами типа записи-члена существует взаимосвязь «один ко многим». Определенный экземпляр типа записи-члена в экземпляре данного типа набора не может одновременно принадлежать более чем одному экземпляру типа записи-владельца. Иными словами уникальность владельца типа набора обязательна.

4.5.1.Представление взаимосвязи «один ко многим»

Вмодели данных, представляющей взаимосвязь «один ко многим», тип записи - владелец «владеет» 0-п экземплярами типа записи-члена.

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

Рис. 4.20

На рис. 4.20 приведены сведения о пациенте, перенесшем несколько операций, и о конкретном типе операции, сделанной нескольким пациентам. Операция, которой подверглись несколько пациентов, будет одновременно членом в двух или более экземплярах одного и того же типа набора, что нарушает правило уникальности владельца. Взаимосвязь «многие ко многим» может быть реализована двумя взаимосвязями «один ко многим».

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

Типами объектов здесь служат: ПАЦИЕНТ, ХИРУРГ и ОПЕРАЦИЯ. Один хирург может прооперировать нескольких пациентов. Один пациент мог быть в свое время прооперирован несколькими хирургами. ПАЦИЕНТ, ХИРУРГ и ОПЕРАЦИЯ образуют сеть. Между ПАЦИЕНТОМ и ХИРУРГОМ существует взаимосвязь «многие ко многим. ПАЦИЕНТ и ХИРУРГ могут рассматриваться

как различные типы записей. Для того чтобы преобразовать взаимосвязь «многие ко многим» между ПАЦИЕНТОМ и ХИРУРГОМ в две взаимосвязи «один ко многим», воспользуемся в качестве связки записью ОПЕРАЦИЯ, которая характеризуется датой операции, видом операции, назначенным после операции препаратом и побочным эффектом от его применения. Отметим, что запись-связка может и не содержать никаких данных. В большинстве случаев она, как правило, включает некоторую полезную информацию, описывающую взаимосвязь между двумя остальными записями.

На рис. 4.21 показаны два типа записи: ПАЦИЕНТ и ОПЕРАЦИЯ. В сетевой модели данных на рис. 4.22 два типа записей образуют набор.

Записи ПАЦИЕНТ и ОПЕРАЦИЯ образуют набор ПАЦИЕНТ ПЕРЕНЕС ОПЕРАЦИЮ. Владельцем является запись ПАЦИЕНТ, а членом — запись ОПЕРАЦИЯ. Записи ХИРУРГ и ОПЕРАЦИЯ образуют набор ОПЕРАЦИЯПАЦИЕНТА.

а

б

Рис 4.21

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

Запись ХИРУРГ называется владельцем, а запись ОПЕРАЦИЯ — членом этого набора.

Каждый экземпляр набора ПАЦИЕНТ-ПЕРЕНЕС-ОПЕРАЦИЮ представляет иерархическую взаимосвязь между пациентом и операцией. Существенное различие между сетевой и иерархической моделями данных состоит в том, что в сетевой модели каждая запись может участвовать в любом

числе наборов и играть роль как владельца, так и члена набора.

Рис. 4.22

Представление данных с помощью сетевой модели взаимосвязи «многие ко многим» реализуется двумя типами наборов:

1)ПАЦИЕНТ-ПЕРЕНЕС-ОПЕРАЦИЮ (запись-владелец ПАЦИЕНТ, запись-член ОПЕРАЦИЯ);

2)ОПЕРАЦИЯ-ПАЦИЕНТА (запись-владелец ХИРУРГ, запись-член ОПЕРАЦИЯ).

4.5.2. Дополнительные классы наборов

Кроме обычных наборов существуют также наборы второго и третьего классов. Второй класс включает наборы, состоящие из трех или более записей. Такой набор называется многочленным. Записью-владельцем здесь является ПАЦИЕНТ, а записями-членами — ОПЕРАЦИЯ и ЗАБОЛЕВАНИЕ (см. рис. 4.23). Показаны один экземпляр записи владельца и. пять экземпляров записей членов.

Рис. 4.23

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

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

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

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

4.5.3.Операции включения и удаления в сетевой модели данных

Включение. Допускается добавление новой записи ХИРУРГ в качестве экземпляра владельца в экземпляр набора ОПЕРАЦИЯ-ПАЦИЕНТА, в котором экземпляр ОПЕРАЦИЯ отсутствует. При этом вводятся сведения о хирурге, не прооперировавшем ни одного пациента. Аналогичным образом можно вводить сведения о пациенте вне зависимости от сведений о хирурге.

Удаление. При удалении экземпляра владельца ХИРУРГ удаляются все указатели, связывающие операции, выполненные хирургом в экземпляре набора ОПЕРАЦИЯ-ПАЦИЕНТА. Информация же о пациентах, которых оперировал данный хирург, не уничтожается. Удаляется информация только о соответствующем хирурге.

Аналогично при удалении экземпляра владельца ПАЦИЕНТ удаляются все указатели, связывающие перенесенные данным пациентом операции в экземпляре набора ПАЦИЕНТ-ПЕРЕНЕС-ОПЕРАЦИЮ. Информация же о хирургах, оперировавших данного пациента, остается неизменной.

4.5.4. Достоинства модели

Главными достоинствами сетевой модели данных являются:

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

•простота реализации часто встречающихся в реальном мире взаимосвязей «многие ко многим».

4.5.5. Недостатки модели

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

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

5. ПРОЕКТИРОВАНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ ДАННЫХ

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

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

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

При проектировании концептуальной модели все усилия разработчика должны быть направлены в основном на структуризацию данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности обработки [4].

5.1.Анализ данных

5.1.1.Сбор информации о данных, используемых в существующих

прикладных программах

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

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

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

1.Имя и описание объекта данных. Указываются основное имя и синонимы. Примеры: «Счета», «Журнал регистрации продукции», «Форма учета счетов». Дается вербальное описание смыслового содержания имени, даже если его смысл представляется очевидным. В общих чертах описывается функциональное назначение и использование объекта в функциональных и структурных подразделениях предприятия, а также за их пределами.

2.Элементы данных. Для каждого элементарного данного, входящего в конкретный объект, указывается:

1)его имя и описание. Перечисляются имена, синонимы и дается их расшифровка. Приводится полное вербальное описание элемента;

2)источник. Перечисляются источники элемента в структуре предприятия, например заказчик, внутренние документы, отдел сбыта;

3)атрибуты. Указываются тип значения атрибута (числовой, алфавитный, текстовый), единицы измерения (доллары, рубли), а при необходимости и допустимые диапазоны значений (например, от 100 до 500);

4)использование элемента данных. Примеры «Содержит сведения об адресе», «Используется для определения количества», «Используется в шкале платежей»;

5)ограничения безопасности/чувствительности. Перечисляются связанные с данным элементом ограничения, включая допущенных к нему лиц и разрешенный им вид обработки, например доступ, чтение и/или выдача;

6)степень важности. Указывается степень важности данного элемента. Она должна определяться значением элемента данных для реализации или расширения функций предприятия. Следует избегать негативных формулировок типа «Без этого элемента данных невозможно выполнить то-то» Рекомендуется приводить аргументы, основываясь на использовании элемента данных (пункт 4);

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

3. Продолжительность хранения и условия перевода в архив. Указывается период времени, в течение которого должны храниться значения элемента данных, и способ хранения. По возможности также указывается основание для хранения (правительственные распоряжения, указания администрации предприятия).

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

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

Рис. 5.1

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

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

5.1.2. Сбор информации о данных для перспективных приложений

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

5.2.Нормализация отношений

Впроцессе нормализации элементы данных группируются в таблицы,