Главная страница
Навигация по странице:

  • 2.3. Дореляционные логические модели данных

  • 2.3.1. Иерархическая модель

  • 2.3.2. Сетевая модель CODASYL

  • 2.4. Реляционная модель данных

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


    Скачать 3.21 Mb.
    НазваниеПрактикум по проектированию, программированию и администрированию баз данных, включающий примеры и практические задания для самостоятельного выполнения
    Дата10.01.2023
    Размер3.21 Mb.
    Формат файлаpdf
    Имя файлаВолк В. - Базы данных. Проектирование, программирование, управле.pdf
    ТипПрактикум
    #879390
    страница2 из 18
    1   2   3   4   5   6   7   8   9   ...   18
    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 / 24

    14
    2.3.1. Иерархическая модель
    Разработчики первых СУБД использовали иерархические модели, кото- рые базировались на древовидных структурах данных, хорошо известных в программировании. Иерархическая база данных представляется множеством деревьев: в вершинах дерева помещаются записи, состоящие из поименованных
    полей и представляющие экземпляры некоторого объекта предметной области.
    Записи связаны строго иерархическими отношениями — у записи-«потомка» не должно быть более одной записи-«предка».
    Одной из первых СУБД, использующих иерархическую модель данных, была разработка компании IBM 1968 г. Information Management System (IMS)
    [32], первоначально предназначавшаяся для управления спецификацией изде- лий аэрокосмической отрасли США. Следует отметить, что такая модель иде- ально подходила для моделируемой предметной области, по своей природе имеющей иерархическую структуру: спецификация технического объекта опи- сывается в терминах «изделие» — «агрегат» — «узел» — «деталь», связанных иерархическим отношением композиции.
    Основным структурным элементом иерархической модели, поддерживае- мой IMS, является так называемый сегмент, представляющий множество одно- типных объектов предметной области. Каждый сегмент может включать ато- марные информационные блоки, называемые «областями» и представляющие атрибуты экземпляров этого объекта. Сегменты модели могут быть иерархиче- ски связаны друг с другом, что отражает определенные семантические отноше- ния между объектами предметной области.
    Например, в базе данных интернет-провайдера (рис. 1.2) корневой сег- мент «Клиенты», включающий области «Имя», «Адрес» и «Телефон», связан с дочерними сегментами «Услуги» и «Заявки», экземпляры которых хранят ин- формацию соответственно об услугах, оказываемых провайдером своим клиен- там, и о поступивших от них заявках.
    Рис. 1.2
    Фрагмент иерархической модели данных
    14 / 24

    15
    В свою очередь, сегмент «Услуги» может быть связан с дочерним сегмен- том «Платежи», каждый экземпляр которого содержит информацию о плате- жах, полученных провайдером за соответствующую услугу, оказанную клиен- ту, а сегмент «Заявки» связан с дочерним сегментом «Работы», представляю- щим работы, выполненные провайдером по заявкам клиентов.
    Главным преимуществом иерархической модели является высокая эф- фективность алгоритмов поиска (стоимость процедуры «спуска по дереву» пропорциональна глубине дерева), а основными ее недостатками считаются вы- сокая стоимость операций модификации (алгоритм расщепления и слияния вершин дерева при вставке и удалении записей) и необходимость дублирования данных при их хранении в БД.
    Причиной дублирования данных является требование строгой иерархич- ности модели в ситуациях, когда в предметной области это требование объек- тивно не соблюдается. Например, если в иерархической БД интернет-провай- дера (рис. 1.2) необходимо дополнительно учитывать распределение работ по выполнению заявок между сотрудниками, потребуется создать дубликаты вер- шин в различных деревьях базы данных (рис. 1.3а). а) б)
    Рис. 1.3
    Дублирование данных в иерархической модели:
    а — иерархическая модель; б — отказ от строгой иерархии.
    Более радикальное решение в такой ситуации (рис. 1.3б) — отказ от иерархической модели данных в пользу сетевой модели, позволяющей связы- вать дочерние сегменты с несколькими родительскими.
    2.3.2. Сетевая модель CODASYL
    В 1969 г. Конференцией по языкам систем данных (Conference on Data
    Systems Languages) была разработана сетевая модель данных, получившая название «модель CODASYL» [18]. Спецификация CODASYL содержит деталь-
    15 / 24

    16
    ную проработку сетевой модели данных, которая, как известно, способна пред- ставлять весьма сложные отношения между элементами данных, но также хо- рошо известны и проблемы программной реализации методов хранения и нави- гационного поиска на такой модели данных (достаточно вспомнить алгоритмы поиска путей на графах, реализованных на списковых структурах).
    Спецификация CODASYL объединяет в себе элементы концептуальной, логической и физической моделей данных: она включает язык определения ло- гической схемы БД, язык манипулирования данными и язык управления внеш- ними носителями данных; для связывания логической схемы БД с файловой структурой данных используется понятие «области базы данных», а для опреде- ления пользовательских представлений БД — понятие «подсхемы». В этой спе- цификации также были определены функции администрирования, включающие операции резервного копирования и восстановления БД, управления производи- тельностью, сбора статистики, аудита, авторизации пользователей и др.
    Основу логической модели данных CODASYL (рис. 1.4) составляют два ее именованных компонента: «запись», поля которой представляют множество свойств моделируемого объекта предметной области, и «набор записей» — двухуровневый граф, моделирующий некоторое иерархическое отношение (аг- регации или обобщения) между реальными объектами.
    Поле записи также является именованным компонентом модели и может быть представлено как атомарным элементом, так и агрегатом, состоящим из атомарных элементов и/или других агрегатов.
    Рис. 1.4
    Компоненты сетевой модели данных CODASYL
    Таким образом, агрегат представляет собой некоторую иерархическую структуру внутри записи и может рассматриваться и как единое целое, и как множество агрегированных элементов. Пример структуры одной из записей ба- зы данных интернет-провайдера представлен на рисунке 1.5.
    Запись «Клиент» включает пять полей, два из которых (Лицевой счет и
    Паспорт) представлены атомарными элементами, а три остальных — агрегата- ми типа «повторяющаяся группа». Агрегат Имя состоит из трех атомарных элементов, агрегат Адрес — из одного атомарного элемента и одного агрегата типа повторяющаяся группа, а агрегат Телефон — из двух атомарных элементов и одного агрегата типа вектор.
    Такая структура записи позволяет простым запросом к БД получить пол- ную информацию о реквизитах клиента, и при этом обеспечивается возмож- ность доступа к отдельным элементам агрегированных полей записи.
    16 / 24

    17
    Рис. 1.5
    Структура записи сетевой модели CODASYL
    Например, можно получить список клиентов, проживающих в определен- ном городе или на определенной улице города, или реализовать функцию авто- дозвона до клиентов, имеющих финансовую задолженность на лицевом счете, последовательно выбирая из базы данных номера их рабочего, домашнего и всех мобильных телефонов.
    Можно также организовать массовую почтовую рассылку писем всем та- ким клиентам с автоматическим заполнением соответствующих адресных по- лей на почтовом конверте, а в тексте письма — с уважительным обращением к каждому клиенту по имени и отчеству (перед стандартным напоминанием о необходимости срочного погашения накопленной задолженности и угрозой су- дебного преследования в противном случае).
    Заметим, что поле Паспорт в этой записи представлено атомарным эле- ментом, хотя реальные паспортные данные клиента — это более сложная структура, которую вполне можно было бы описать агрегатом вида «серия —
    номер — дата выдачи — место выдачи». Возможно, решение об атомарности этого поля было принято разработчиком модели по результатам анализа поль- зовательских запросов к проектируемой базе данных, который показал, что паспортные данные клиента необходимы только для автоматизированного формирования заключительного раздела клиентского договора.
    В модели данных CODASYL «записи» могут объединяться в «наборы» — двухуровневые иерархические структуры, в каждой из которых одна запись яв- ляется «владельцем», а другая — «членом» набора. Запись может быть членом и одновременно владельцем нескольких разных наборов (что, собственно, и определяет сетевой характер этой модели), однако в наборе должна соблюдать- ся иерархия экземпляров записей: экземпляр записи-владельца может быть свя- зан с несколькими экземплярами записей-членов, но экземпляр записи-члена не может быть связан более чем с одним экземпляром-владельцем.
    На базе спецификации CODASYL Чарльзом Бахманом (C. W. Bachman) была разработана система графического отображения сетевой модели данных
    [16], получившая название «диаграмма Бахмана» и дающая программисту визу-
    17 / 24

    18
    альное представление о структуре записей, их параметрах, а также об отноше- ниях между объектами и путях навигационного поиска данных.
    На рисунке 1.6 представлен фрагмент упрощенной диаграммы Бахмана, описывающей сетевую модель базы данных интернет-провайдера, иерархиче- ская модель которой была рассмотрена выше (рис. 1.2 и 1.3а). Наборы записей на диаграмме обозначены линиями со стрелками, направленными от записей- владельцев к записям-членам наборов.
    Рис. 1.6
    Графическое представление фрагмента модели CODASYL
    Набор «Услуги
    Тарифы» представляет собой модель прайс-листа интер- нет-провайдера: с каждым экземпляром записи-владельца «Услуги» связано множество экземпляров записи-члена «Тарифы». Клиентская база провайдера представлена набором «Клиенты
    Договоры», а содержательная часть догово- ров с клиентами — набором «Договоры
    Тарифы». Экземпляр записи «Тари-
    фы», являясь членом двух наборов, представляет один из тарифов одной из услуг, предоставляемых клиенту по одному из заключенных им договоров.
    Набор «Клиенты
    Заявки» — это модель журнала заявок от клиентов, принятых сотрудником call-центра, а набор «Заявки
    Работы» определяет со- став работ, требующих выполнения для исполнения заявок. Два набора —
    «Отделы
    Должности» и «ДолжностиСотрудники» представляют штатное расписание отделов, а набор «Сотрудники
    Работы» — распределение работ, связанных с выполнением заявок, между сотрудниками отделов.
    Запись «Платежи» является членом трех различных наборов: экземпляр этой записи представляет один платеж либо за оказанную клиенту услугу по одному из договоров, либо за выполненную работу по одной из заявок, посту- пивших от клиента.
    Модель CODASYL предоставляет разработчику два метода хранения и извлечения записей: метод прямого доступа, использующий алгоритм хеширо- вания, и метод связанных списков, использующий систему указателей, устанав-
    18 / 24

    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 / 24

    20
    тальная подготовка доктора Кодда, предположившего, что базу данных можно представлять в виде набора отношений (relationships), к которым прямо приме- нимы языки и понятия математической логики и над которыми допустимо вы- полнение операций реляционной алгебры (также разработанной Коддом и включающей специальное расширение теоретико-множественных операций).
    Реляционная база данных — это множество взаимосвязанных именован- ных отношений. Отношение — это информационная модель реального объекта
    («сущности») предметной области, формально представленная множеством од- нотипных кортежей. Кортеж отношения представляет экземпляр моделируемо- го объекта, свойства которого определяются значениями соответствующих ат- рибутов («полей») кортежа.
    Связи между кортежами отношений (при их наличии) реализуются через простой механизм «внешних ключей», являющихся, по существу, ссылками на атрибуты связываемых кортежей нескольких отношений.
    В реализации кортеж отношения является аналогом записи модели
    CODASYL, а атрибут кортежа — аналогом поля записи с той лишь разницей, что реляционная модель не допускает никакой внутренней структуры атрибу- тов отношений — все они должны быть атомарными. Такое упрощение позво- ляет ассоциировать отношения реляционной БД с прямоугольными плоскими таблицами, а кортежи отношений — со строками таких таблиц, что упрощает представление о структуре базы данных и делает их доступными даже конеч- ным пользователям, не являющимся специалистами в области IT
    1
    Несмотря на то что реляционная модель данных объективно проигрывает иерархической и сетевой моделям по информативности и скорости доступа к данным, ее основное преимущество — в простоте представления структуры БД и, как следствие, в высокой технологичности разработки БД, а также в эффек- тивности выполнения модифицирующих операций
    2
    Первой реляционной СУБД была System R [30], созданная в середине
    1970-х гг. корпорацией IBM в результате выполнения исследовательского про- екта. Многие архитектурные решения и алгоритмы, реализованные в System R, были использованы при разработке последующих коммерческих реляционных
    СУБД. System R была также первой СУБД, поддерживающей язык SQL.
    Увеличение аппаратной мощности компьютеров, переход на мини-ЭВМ, внедрение клиент-серверной архитектуры вычислительных систем привели к тому, что к середине 1980-х гг. высокая технологичность реляционных СУБД сделала их более популярными, а их традиционная критика за низкую произво- дительность перестала быть актуальной.
    1
    Подтверждением тезиса об «общедоступности» реляционных баз данных может служить факт включения реляционных СУБД в популярные пакеты офисных приложений наряду с органайзерами, текстовыми редакторами и электронными таблицами.
    2
    Чтобы убедиться в правомерности такого утверждения, полезно сравнить по производи- тельности типовые алгоритмы вставки/удаления узла графа или вершины дерева с алгорит- мом вставки/удаления строки в неотсортированной таблице.
    20 / 24

    21
    В результате реляционные системы постепенно вытеснили с рынка не- удобные в разработке и негибкие при эксплуатации иерархические и сетевые
    CODASYL-системы, получившие общее название «дореляционных» СУБД.
    1   2   3   4   5   6   7   8   9   ...   18


    написать администратору сайта