Волк В.К. Базы данных. Практикум по проектированию, программированию и администрированию баз данных, включающий примеры и практические задания для самостоятельного выполнения
 Скачать 3.17 Mb.
|
|
2.2. Концептуальная модель предметной области АИС Информационное моделирование бизнес-процессов было введено в прак- тику проектирования БД работами Брауна (A. P. G. Brown) [17], Чена (P. Chen) [14, 21] и ряда других авторов [33] в 1960–1970-х гг. В этих работах была пред- ложена концептуальная модель предметной области, представляющая резуль- тат ее объектной декомпозиции. В основе концептуальной модели лежали по- нятия сущности (entity) и связи (relationship), рассматриваемые как абстракции реальных моделируемых объектов и семантических отношений между ними. Такая модель получила название ER-модели, или модели «сущность — связь». Каждая сущность в такой модели представляет множество однотипных экземпляров некоторого объекта предметной области и наделяется «атрибута- ми», описывающими свойства объектов, существенные в рамках решаемой за- дачи. Множество значений описательных атрибутов экземпляров сущностей является основным результатом выполнения пользовательских запросов к базе данных, при этом некоторые атрибуты могут выступать и в роли идентифика- торов, с помощью которых производится выборка соответствующих экземпля- ров. Связи между сущностями представляют отношения между реальными объектами и обеспечивают возможность навигационного поиска экземпляров одних сущностей по их связям с другими экземплярами. Для визуального представления ER-модели было разработано несколько систем графической нотации, на их основе созданы CASE-средства, многие из которых и сегодня эффективно используются на начальных стадиях проектов баз данных. Считается, что ER-диаграмма, известная также как диаграмма Че- на, положила начало разработке средств графического моделирования, исполь- зуемых при проектировании программных систем. Среди множества диаграмм современного языка графического моделирования UML одно из центральных мест занимает диаграмма классов, унаследовавшая основные свойства ER- диаграммы. 2.3. Дореляционные логические модели данных Логическая модель данных формируется на базе концептуальной модели и представляет собой ее детализацию и последующее описание на некотором высо- коуровневом языке, поддерживаемом СУБД. Качество логической модели во мно- гом определяет эффективность алгоритмов поиска данных, реализуемых СУБД. 13 / 19 14 2.3.1. Иерархическая модель Разработчики первых СУБД использовали иерархические модели, кото- рые базировались на древовидных структурах данных, хорошо известных в программировании. Иерархическая база данных представляется множеством деревьев: в вершинах дерева помещаются записи, состоящие из поименованных полей и представляющие экземпляры некоторого объекта предметной области. Записи связаны строго иерархическими отношениями — у записи-«потомка» не должно быть более одной записи-«предка». Одной из первых СУБД, использующих иерархическую модель данных, была разработка компании IBM 1968 г. Information Management System (IMS) [32], первоначально предназначавшаяся для управления спецификацией изде- лий аэрокосмической отрасли США. Следует отметить, что такая модель иде- ально подходила для моделируемой предметной области, по своей природе имеющей иерархическую структуру: спецификация технического объекта опи- сывается в терминах «изделие» — «агрегат» — «узел» — «деталь», связанных иерархическим отношением композиции. Основным структурным элементом иерархической модели, поддерживае- мой IMS, является так называемый сегмент, представляющий множество одно- типных объектов предметной области. Каждый сегмент может включать ато- марные информационные блоки, называемые «областями» и представляющие атрибуты экземпляров этого объекта. Сегменты модели могут быть иерархиче- ски связаны друг с другом, что отражает определенные семантические отноше- ния между объектами предметной области. Например, в базе данных интернет-провайдера (рис. 1.2) корневой сег- мент «Клиенты», включающий области «Имя», «Адрес» и «Телефон», связан с дочерними сегментами «Услуги» и «Заявки», экземпляры которых хранят ин- формацию соответственно об услугах, оказываемых провайдером своим клиен- там, и о поступивших от них заявках. Рис. 1.2 Фрагмент иерархической модели данных 14 / 19 15 В свою очередь, сегмент «Услуги» может быть связан с дочерним сегмен- том «Платежи», каждый экземпляр которого содержит информацию о плате- жах, полученных провайдером за соответствующую услугу, оказанную клиен- ту, а сегмент «Заявки» связан с дочерним сегментом «Работы», представляю- щим работы, выполненные провайдером по заявкам клиентов. Главным преимуществом иерархической модели является высокая эф- фективность алгоритмов поиска (стоимость процедуры «спуска по дереву» пропорциональна глубине дерева), а основными ее недостатками считаются вы- сокая стоимость операций модификации (алгоритм расщепления и слияния вершин дерева при вставке и удалении записей) и необходимость дублирования данных при их хранении в БД. Причиной дублирования данных является требование строгой иерархич- ности модели в ситуациях, когда в предметной области это требование объек- тивно не соблюдается. Например, если в иерархической БД интернет-провай- дера (рис. 1.2) необходимо дополнительно учитывать распределение работ по выполнению заявок между сотрудниками, потребуется создать дубликаты вер- шин в различных деревьях базы данных (рис. 1.3а). а) б) Рис. 1.3 Дублирование данных в иерархической модели: а — иерархическая модель; б — отказ от строгой иерархии. Более радикальное решение в такой ситуации (рис. 1.3б) — отказ от иерархической модели данных в пользу сетевой модели, позволяющей связы- вать дочерние сегменты с несколькими родительскими. 2.3.2. Сетевая модель CODASYL В 1969 г. Конференцией по языкам систем данных (Conference on Data Systems Languages) была разработана сетевая модель данных, получившая название «модель CODASYL» [18]. Спецификация CODASYL содержит деталь- 15 / 19 16 ную проработку сетевой модели данных, которая, как известно, способна пред- ставлять весьма сложные отношения между элементами данных, но также хо- рошо известны и проблемы программной реализации методов хранения и нави- гационного поиска на такой модели данных (достаточно вспомнить алгоритмы поиска путей на графах, реализованных на списковых структурах). Спецификация CODASYL объединяет в себе элементы концептуальной, логической и физической моделей данных: она включает язык определения ло- гической схемы БД, язык манипулирования данными и язык управления внеш- ними носителями данных; для связывания логической схемы БД с файловой структурой данных используется понятие «области базы данных», а для опреде- ления пользовательских представлений БД — понятие «подсхемы». В этой спе- цификации также были определены функции администрирования, включающие операции резервного копирования и восстановления БД, управления производи- тельностью, сбора статистики, аудита, авторизации пользователей и др. Основу логической модели данных CODASYL (рис. 1.4) составляют два ее именованных компонента: «запись», поля которой представляют множество свойств моделируемого объекта предметной области, и «набор записей» — двухуровневый граф, моделирующий некоторое иерархическое отношение (аг- регации или обобщения) между реальными объектами. Поле записи также является именованным компонентом модели и может быть представлено как атомарным элементом, так и агрегатом, состоящим из атомарных элементов и/или других агрегатов. Рис. 1.4 Компоненты сетевой модели данных CODASYL Таким образом, агрегат представляет собой некоторую иерархическую структуру внутри записи и может рассматриваться и как единое целое, и как множество агрегированных элементов. Пример структуры одной из записей ба- зы данных интернет-провайдера представлен на рисунке 1.5. Запись «Клиент» включает пять полей, два из которых (Лицевой счет и Паспорт) представлены атомарными элементами, а три остальных — агрегата- ми типа «повторяющаяся группа». Агрегат Имя состоит из трех атомарных элементов, агрегат Адрес — из одного атомарного элемента и одного агрегата типа повторяющаяся группа, а агрегат Телефон — из двух атомарных элементов и одного агрегата типа вектор. Такая структура записи позволяет простым запросом к БД получить пол- ную информацию о реквизитах клиента, и при этом обеспечивается возмож- ность доступа к отдельным элементам агрегированных полей записи. 16 / 19 17 Рис. 1.5 Структура записи сетевой модели CODASYL Например, можно получить список клиентов, проживающих в определен- ном городе или на определенной улице города, или реализовать функцию авто- дозвона до клиентов, имеющих финансовую задолженность на лицевом счете, последовательно выбирая из базы данных номера их рабочего, домашнего и всех мобильных телефонов. Можно также организовать массовую почтовую рассылку писем всем та- ким клиентам с автоматическим заполнением соответствующих адресных по- лей на почтовом конверте, а в тексте письма — с уважительным обращением к каждому клиенту по имени и отчеству (перед стандартным напоминанием о необходимости срочного погашения накопленной задолженности и угрозой су- дебного преследования в противном случае). Заметим, что поле Паспорт в этой записи представлено атомарным эле- ментом, хотя реальные паспортные данные клиента — это более сложная структура, которую вполне можно было бы описать агрегатом вида «серия — номер — дата выдачи — место выдачи». Возможно, решение об атомарности этого поля было принято разработчиком модели по результатам анализа поль- зовательских запросов к проектируемой базе данных, который показал, что паспортные данные клиента необходимы только для автоматизированного формирования заключительного раздела клиентского договора. В модели данных CODASYL «записи» могут объединяться в «наборы» — двухуровневые иерархические структуры, в каждой из которых одна запись яв- ляется «владельцем», а другая — «членом» набора. Запись может быть членом и одновременно владельцем нескольких разных наборов (что, собственно, и определяет сетевой характер этой модели), однако в наборе должна соблюдать- ся иерархия экземпляров записей: экземпляр записи-владельца может быть свя- зан с несколькими экземплярами записей-членов, но экземпляр записи-члена не может быть связан более чем с одним экземпляром-владельцем. На базе спецификации CODASYL Чарльзом Бахманом (C. W. Bachman) была разработана система графического отображения сетевой модели данных [16], получившая название «диаграмма Бахмана» и дающая программисту визу- 17 / 19 18 альное представление о структуре записей, их параметрах, а также об отноше- ниях между объектами и путях навигационного поиска данных. На рисунке 1.6 представлен фрагмент упрощенной диаграммы Бахмана, описывающей сетевую модель базы данных интернет-провайдера, иерархиче- ская модель которой была рассмотрена выше (рис. 1.2 и 1.3а). Наборы записей на диаграмме обозначены линиями со стрелками, направленными от записей- владельцев к записям-членам наборов. Рис. 1.6 Графическое представление фрагмента модели CODASYL Набор «Услуги →Тарифы» представляет собой модель прайс-листа интер- нет-провайдера: с каждым экземпляром записи-владельца «Услуги» связано множество экземпляров записи-члена «Тарифы». Клиентская база провайдера представлена набором «Клиенты →Договоры», а содержательная часть догово- ров с клиентами — набором «Договоры →Тарифы». Экземпляр записи «Тари- фы», являясь членом двух наборов, представляет один из тарифов одной из услуг, предоставляемых клиенту по одному из заключенных им договоров. Набор «Клиенты →Заявки» — это модель журнала заявок от клиентов, принятых сотрудником call-центра, а набор «Заявки →Работы» определяет со- став работ, требующих выполнения для исполнения заявок. Два набора — «Отделы →Должности» и «Должности→Сотрудники» представляют штатное расписание отделов, а набор «Сотрудники →Работы» — распределение работ, связанных с выполнением заявок, между сотрудниками отделов. Запись «Платежи» является членом трех различных наборов: экземпляр этой записи представляет один платеж либо за оказанную клиенту услугу по одному из договоров, либо за выполненную работу по одной из заявок, посту- пивших от клиента. Модель CODASYL предоставляет разработчику два метода хранения и извлечения записей: метод прямого доступа, использующий алгоритм хеширо- вания, и метод связанных списков, использующий систему указателей, устанав- 18 / 19 19 ливающих отношения между записями, в том числе между членами и владель- цами наборов. Предусмотрены многочисленные возможности управления фор- матом записей и средства ускорения доступа к данным, например размещение на одном физическом устройстве (файле) записей-членов и записей-владельцев одного набора. Преимуществами сетевой модели CODASYL являются способность пред- ставлять сложно структурированные свойства информационных объектов и сложные отношения между ними, что позволяет адекватно моделировать свой- ства практически любой предметной области, а также высокая производитель- ность за счет гибкого управления физической моделью данных. Недостатки спецификации CODASYL — это обратная сторона ее пре- имуществ, их обычно связывают с двумя основными факторами. Во-первых, это сложность самой сетевой модели данных и, как следствие, высокая трудоемкость освоения технологии ее разработки. Разработка, анализ и модификация структуры сетевой базы данных (даже при использовании визу- альных средств моделирования и наличии специально подготовленных специа- листов) могли занимать весьма длительный период. Во-вторых, достижение высокой производительности выполнения опера- ций извлечения данных потребовало детального описания физической модели данных, что сделало операции загрузки БД и изменения ее структуры крайне дорогостоящими. В условиях, когда ключ записи напрямую связан с ее физиче- ским адресом и одновременно используется в качестве указателя для реализа- ции наборов данных в виде связанных списков и деревьев, для создания новых связей требуется перестройка БД на физическом уровне. В 1970 г. на базе сетевой модели была разработана СУБД IDMS (Integrated Database Management System) [19], послужившая платформой для создания многих корпоративных систем обработки данных. Несмотря на отме- ченные выше недостатки сетевой модели CODASYL, построенные на ее основе базы данных в то время намного превосходили по производительности и эф- фективности хранения данных параллельно развивавшиеся реляционные си- стемы. 2.4. Реляционная модель данных Теоретические разработки в области реляционных моделей данных были выполнены в 1960–1970-х гг. Коддом (E. F. Codd) [22–24] и позднее Дейтом (C. J. Date) и Дарвеном (H. Darwen) [4, 25–29]. Имеются многочисленные пуб- ликации, посвященные теории и практике применения реляционной модели [7, 8, 13, 14]. Отметим основные идеи, положенные в основу реляционного под- хода и позволившие реляционным системам вначале составить серьезную кон- куренцию иерархическим и сетевым базам данных, а затем практически вытес- нить их с рынка СУБД, используемых в АИС массового применения. В отличие от модели CODASYL, базирующейся на чисто программист- ских решениях, реляционная модель имеет строгую математическую основу — математическую логику и теорию множеств. Очевидно, сказалась фундамен- 19 / 19 20 тальная подготовка доктора Кодда, предположившего, что базу данных можно представлять в виде набора отношений (relationships), к которым прямо приме- нимы языки и понятия математической логики и над которыми допустимо вы- полнение операций реляционной алгебры (также разработанной Коддом и включающей специальное расширение теоретико-множественных операций). Реляционная база данных — это множество взаимосвязанных именован- ных отношений. Отношение — это информационная модель реального объекта («сущности») предметной области, формально представленная множеством од- нотипных кортежей. Кортеж отношения представляет экземпляр моделируемо- го объекта, свойства которого определяются значениями соответствующих ат- рибутов («полей») кортежа. Связи между кортежами отношений (при их наличии) реализуются через простой механизм «внешних ключей», являющихся, по существу, ссылками на атрибуты связываемых кортежей нескольких отношений. В реализации кортеж отношения является аналогом записи модели CODASYL, а атрибут кортежа — аналогом поля записи с той лишь разницей, что реляционная модель не допускает никакой внутренней структуры атрибу- тов отношений — все они должны быть атомарными. Такое упрощение позво- ляет ассоциировать отношения реляционной БД с прямоугольными плоскими таблицами, а кортежи отношений — со строками таких таблиц, что упрощает представление о структуре базы данных и делает их доступными даже конеч- ным пользователям, не являющимся специалистами в области IT 1 Несмотря на то что реляционная модель данных объективно проигрывает иерархической и сетевой моделям по информативности и скорости доступа к данным, ее основное преимущество — в простоте представления структуры БД и, как следствие, в высокой технологичности разработки БД, а также в эффек- тивности выполнения модифицирующих операций 2 Первой реляционной СУБД была System R [30], созданная в середине 1970-х гг. корпорацией IBM в результате выполнения исследовательского про- екта. Многие архитектурные решения и алгоритмы, реализованные в System R, были использованы при разработке последующих коммерческих реляционных СУБД. System R была также первой СУБД, поддерживающей язык SQL. Увеличение аппаратной мощности компьютеров, переход на мини-ЭВМ, внедрение клиент-серверной архитектуры вычислительных систем привели к тому, что к середине 1980-х гг. высокая технологичность реляционных СУБД сделала их более популярными, а их традиционная критика за низкую произво- дительность перестала быть актуальной. 1 Подтверждением тезиса об «общедоступности» реляционных баз данных может служить факт включения реляционных СУБД в популярные пакеты офисных приложений наряду с органайзерами, текстовыми редакторами и электронными таблицами. 2 Чтобы убедиться в правомерности такого утверждения, полезно сравнить по производи- тельности типовые алгоритмы вставки/удаления узла графа или вершины дерева с алгорит- мом вставки/удаления строки в неотсортированной таблице. 1 / 19 |