Semantic method of database designing and its prospects opening withapplication of the ERM data model.pdf Как только появились первые СУБД, люди задумались над проблемой проек-тирования эффективной схемы для каждого случая применения технологии БД.Достаточно стройной и конструктивной является классическая методика деком-позиции отношений, предложенная для реляционной модели данных [1 - 4].Однако трудно не согласиться с мнением многих авторов [3, 4], утверждаю-щих, что практическое ее использование осложняется такими факторами, как:- нетрадиционный для большинства людей и весьма нетривиальный способвосприятия и формализации предметной области (ПрО);- практическая неприменимость для сложных ПрО;- неоднозначность решения проблемы проектирования, приводящая к прямомуперебору многочисленных вариантов схемы в поисках наиболее подходящего.Непрекращающиеся поиски решения проблемы проектирования БД привели кпоявлению семантических моделей данных, которые обеспечивают высокоуров-невое формальное представление ПрО. Они должны были устранить первые дванедостатка классической методики - неестественность представлений для челове-ка и неприменимость для сложных ПрО.Но, поскольку коммерческие СУБД не собираются поддерживать напрямуюсемантические модели данных, необходима трансляция схем БД с языка этих мо-делей на язык СУБД и в первую очередь - реляционных. Примерно так, практиче-ски с первых публикаций по ER-модели [5] стала вырисовываться основная схемасемантической методики проектирования реляционных БД.1. Этапы семантической методикиО семантической методике можно говорить в узком и широком смысле. Еслирассматривать только те задачи проектирования, которые решает классическаяреляционная методика, то последовательность шагов семантической методикивыглядит следующим образом:- проектирование семантической схемы ПрО с использованием той или инойсемантической модели данных;- перевод полученной схемы в реляционную модель с применением подходя-щего набора правил трансформации и получение множества предварительных от-ношений;- проверка полученных отношений на удовлетворение требований нормальныхформ и их дальнейшая нормализация методом декомпозиции.Все семантические методики действуют по одной и той же схеме и отличаютсялишь используемыми моделями и правилами трансляции схем.Если рассматривать задачу проектирования схемы БД для конкретной СУБДмаксимально широко, начиная с первоначальной постановки задачи и заканчиваяполностью готовой схемой, реализованной в этой СУБД, можно говорить о трехдополнительных этапах:- предшествующее собственно моделированию данных функциональное моде-лирование бизнес-процессов предприятия, для информационного обеспечения ко-торых создается БД;- повышение эффективности полученной логической схемы БД за счет внесе-ния управляемой избыточности (денормализация);- повышение эффективности схемы БД за счет физического проектирования,учитывающего особенности хранения данных на диске и методов доступа к ним вконкретной СУБД.Ограничение на объем статьи не позволяет осветить должным образом эти во-просы, поэтому в дальнейшем речь пойдет о трех основных этапах методики. От-метим лишь, что передача логической схемы СУБД сопровождается созданиемдополнительных элементов БД, таких, как динамические представления, тригге-ры, процедуры, функции и так далее.2. Факторы, влияющие на результат проектированияУспех применения семантической методики проектирования БД помимо зна-ний и умений человека определяют два фактора:- мощность выразительных средств используемой семантической модели,- детальность анализа семантической схемы БД в применяемых правилахтрансляции.Выбор неадекватных инструментов может полностью дискредитировать мето-дику. Так, невыразительная ER-модель нотации IDEF1X вынуждает проектиров-щика еще на этапе анализа семантики ПрО принимать сугубо технические реше-ния (например, сводить бинарное множество связей типа M:N к дополнительныммножеству сущностей и паре множеств связей). Это происходит в силу того, чтоэта модель отличается от реляционной модели, по сути, взаимно-однозначнымпереименованием понятий: «множество сущностей» - «отношение», «множествосвязей» - «ограничение ссылочной целостности», «атрибут множества сущно-стей» - «атрибут отношения». А это свидетельствует о том, что уровень ее «се-мантичности» такой же, как и у реляционной модели.Совмещение двух в принципе различных мыслительных процессов - выявле-ния семантики ПрО и определения схемы БД на весьма абстрактном языке СУБД- еще полбеды. Хуже то, что принимаемые в ходе этого технические решения(например, введение дополнительного множества сущностей и бинарных мно-жеств связей вместо множества связей степени больше двух) должны быть по-хорошему проанализированы заново на этапе окончательного построения реляци-онной схемы. В противном случае можно получить не самую эффективную схемуБД.Что уж говорить о бизнес-правилах, которые потребуют процедурной (а недекларативной) реализации на языке СУБД. На этапе семантического анализа их влучшем случае фиксируют в виде текстовых описаний. Естественно, никакие пра-вила трансляции для таких бизнес-правил не предусматриваются. Дай бог, чтобыпроектировщик не забыл о них на последнем этапе разработки БД и вручную соз-дал необходимые для их проверки триггеры.Для иллюстрации влияния детальности правил трансляции рассмотрим по од-ному правилу из трех разных наборов, разработанных для преобразования схемыиз ER-модели Чена в реляционную модель.1. Для каждого множества сущностей и каждого множества связей создатьсобственное отношение.2. Бинарные множества связей типа 1:1 или 1:M представляются дублировани-ем первичного ключа 1-отношения в M-отношение (1-отношение - это отноше-ние, построенное для представления множества сущностей, возле которого наребре роли указана 1. Для M-отношения - соответственно, M) [1].3. Каждое бинарное множество связей типа 1:1, у которого класс принадлеж-ности обоих сущностей является обязательным, и множества сущностей, в немучаствующие, заменяются в ER-схеме одним агрегированным множеством сущ-ностей, с которым соединяются все другие множества связей, имевшиеся у двухисходных множеств сущностей. Вновь образованное множество сущностей поро-ждает одно отношение в реляционной схеме [4].Посмотрим, какие результаты будут получены спомощью этих правил для ER-схемы, приведеннойна рис. 1.Применение первого правила породит три от-ношения, по одному на каждое множество. По вто-рому правилу в реляционной схеме будет построе-но два отношения. Этот прогресс (в смысле качест-ва результата) объясняется дополнительным анали-зом максимальных кардинальных чисел отображе-ний, определяемых множеством связей. И, наконец,третье правило приведет к одному отношению,наилучшим образом подходящему в нашем случае.Таким результатом мы обязаны дополнительномурассмотрению минимальных кардинальных чиселупомянутых отображений. Как видим, детальностьанализа семантической схемы повышает эффек-тивность результирующей схемы.3. Идеальная схема применения семантической методикиВыбор семантической модели и набора правил преобразования схем во мно-гом определяет успех проектирования. Конечно, хорошо, когда семантическая ме-тодика реализована в виде программного CASE-средства, но часто лучше провес-ти проектирование на бумаге, используя мощную модель и правила, чем восполь-зоваться тривиальным автоматизированным помощником.Персонал1ПалатаЕПерсоналпалаты1Рис. 1. Пример ER-диаграммы(нотация Чена)Идеальное применение семантической методики характеризуется следующимичертами.1. На этапе первоначальной формализации описаний ПрО в рамках семантическоймодели схема данных должна вобрать в себя определения всех основных понятийПрО и всех закономерностей взаимоотношений между ними. Для этого используемаясемантическая модель должна быть в состоянии представить любые требования,предъявляемые к данным. Идеальная семантическая схема ПрО должна содержать ееполное формальное описание с тем, чтобы все последующие межмодельные преобра-зования схемы носили чисто синтаксический характер и не требовали повторногоанализа семантики ПрО и работы с текстами на естественном языке.2. Детальность применяемых в методике правил трансформации схемы должнабыть такой, чтобы не оставить без внимания ни один элемент семантической схемы.Это в сочетании с доказанной надежностью и эффективностью правил позволит га-рантировать идеальную со всех точек зрения СУБД-ориентированную схему.Если к этому добавить средства автоматизации процесса проектирования в ви-де соответствующего CASE-инструмента, то получится идеальная реализация се-мантической методики. Подобная система, с одной стороны, облегчит построениесемантической схемы ПрО, с другой - полностью автоматизирует процесс полу-чения реляционной схемы и ее передачу целевой СУБД.4. Ручное применение методики на примере ER-моделиПродемонстрируем применение семантической методики человеком безсредств автоматизации. В примере используется классическая ER-модель Чена срасширением в виде специализаций [2] и средний по детальности анализа наборправил трансляции схем. В качестве предметной области выбраны родственныеотношения между людьми. На рис. 2 приведена ER-диаграмма этой ПрО в нота-ции Чена (атрибуты и множества значений опущены).МатьEРождениеМуж1Мать1ОтецЧеловекЖенщина МужчинаБракЖена1РебенокMОтец1EРодитель-РебенокРебенокМРодительNddd  Рис. 2. ER-диаграмма родственных отношений (нотация Чена)Если к этой ER-диаграмме добавить однозначные атрибуты множества сущно-стей ЧЕЛОВЕК (ФИО CHARACTER(50), ПОЛ CHARACTER(10)), мы получимисходную ER-схему этой ПрО.Приведем один из традиционно используемых наборов правил трансформациисхем ПрО из ER-модели Чена в реляционную модель.1. Каждое множество сущностей представляется самостоятельным отношени-ем, однозначные атрибуты множества сущностей становятся атрибутами отноше-ния, ключи множества сущностей являются возможными ключами отношения;при необходимости в качестве первичного ключа отношения используется сурро-гатный атрибут.Применяя это правило, мы получим первые пять отношений нашей схемы:ЧЕЛОВЕК (ЧЕЛОВЕК_ID NUMBER(10, 0), ФИО CHARACTER(50), ПОЛCHARACTER(10)),ЖЕНЩИНА (ЖЕНЩИНА_ID NUMBER(10, 0)),МУЖЧИНА (МУЖЧИНА_ID NUMBER(10, 0)),МАТЬ (МАТЬ_ID NUMBER(10, 0)),ОТЕЦ (ОТЕЦ_ID NUMBER(10, 0)).2. Бинарные множества связей типа 1:1 и 1:M без атрибутов представляютсядублированием первичного ключа 1-отношения в M-отношение.В соответствии с этим правилом добавлен атрибут МУЖЧИНА_ID в отноше-ние ЖЕНЩИНА: ЖЕНЩИНА (ЖЕНЩИНА_ID NUMBER(10, 0), МУЖЧИНА_IDNUMBER(10, 0)). Поскольку роли мужчин и женщин в браках абсолютно равно-правны, можно было проделать симметричное изменение отношения МУЖЧИНА.3. Бинарные множества связей типа M:N без атрибутов представляются само-стоятельными отношениями, куда дублируются первичные ключи отношений,построенных для множеств сущностей.По этому правилу построено отношение РОДИТЕЛЬ-РЕБЕНОК (РОДИ-ТЕЛЬ_ID NUMBER(10, 0), РЕБЕНОК_ID NUMBER(10, 0)).4. Множества связей с атрибутами представляются самостоятельными отно-шениями, куда дублируются первичные ключи отношений, построенных длямножеств сущностей. Однозначные атрибуты множества связей становятся атри-бутами этого отношения.В нашей ER-схеме не было множеств связей такого рода.5. Множества связей степени больше двух представляются самостоятельнымиотношениями, куда дублируются первичные ключи отношений, построенных длямножеств сущностей. Однозначные атрибуты множества связей становятся атри-бутами этого отношения.По этому правилу построено отношение РОЖДЕНИЕ (РЕБЕНОК_IDNUMBER(10, 0), МАТЬ_ID NUMBER(10, 0), ОТЕЦ_ID NUMBER(10, 0)).6. Каждый многозначный атрибут множества сущностей представляется от-дельным отношением, куда дублируется первичный ключ отношения, построен-ного для множества сущностей; второй атрибут этого отношения предназначенсобственно для значения.В нашей ER-схеме атрибутов такого рода у множеств сущностей не было.7. Каждый многозначный атрибут множества связей представляется отдель-ным отношением, куда дублируется первичный ключ отношения, построенногодля множества связей; второй атрибут этого отношения предназначен собственнодля значения.В нашей ER-схеме атрибутов такого рода у множеств связей не было.8. Каждая ветвь специализаций трактуется как обычное бинарное множествосвязей типа 1:1, которое преобразуется согласно второму правилу.В соответствии с этим правилом первичные ключи отношений-родителейсдублированы в дочерние отношения.В результате применения указанных правил получились следующие отноше-ния реляционной модели:ЧЕЛОВЕК (ЧЕЛОВЕК_ID NUMBER(10, 0), ФИО CHARACTER(50), ПОЛCHARACTER(10)),ЖЕНЩИНА (ЖЕНЩИНА_ID NUMBER(10, 0) , ЧЕЛОВЕК_ID NUMBER(10, 0),МУЖЧИНА_ID NUMBER(10, 0)),МУЖЧИНА (МУЖЧИНА_ID NUMBER(10, 0), ЧЕЛОВЕК_ID NUMBER(10, 0)),МАТЬ (МАТЬ_ID NUMBER(10, 0), ЖЕНЩИНА_ID NUMBER(10, 0)),ОТЕЦ (ОТЕЦ_ID NUMBER(10, 0), МУЖЧИНА_ID NUMBER(10, 0)),РОДИТЕЛЬ-РЕБЕНОК (РОДИТЕЛЬ_ID NUMBER(10, 0), РЕБЕНОК_IDNUMBER(10, 0)),РОЖДЕНИЕ (РЕБЕНОК_ID NUMBER(10, 0), МАТЬ_ID NUMBER(10, 0),ОТЕЦ_ID NUMBER(10, 0)).5. Автоматизированное применение методики на примере Oracle DesignerВ качестве примера автоматизированного применения методики рассмотримпроцесс проектирования реляционной схемы БД для той же ПрО с использовани-ем интегрированной CASE-системы Oracle Designer. Ее ER-диаграммер использу-ет ER-модель в нотации Баркера.По сравнению с ER-моделью Чена в ней отсутствуют:- множества связей степени больше двух,- атрибуты множеств связей,- многозначные атрибуты,- атрибутивные отображения в декартово произведение множеств значений.Давайте проанализируем, какие «технические решения» предстоит предпри-нимать проектировщику схемы БД, выбравшему в качестве семантической моде-ли ER-модель Баркера.Если ему необходимо представить множество связей степени n, придется ис-пользовать вспомогательное множество сущностей и n бинарных множеств связей.В случае наличия атрибутов у множества связей универсальным решением яв-ляется замена этого множества связей множеством сущностей и бинарными мно-жествами связей. Однозначные атрибуты бывшего множества связей станут атри-бутами нового множества сущностей.Многозначные атрибуты множеств сущностей и множеств связей потребуютсоздания для каждого такого атрибута самостоятельного множества сущностей сатрибутом для значений и бинарного множества связей типа 1:M между множест-вом - владельцем многозначного атрибута и новым множеством сущностей. Оче-видно, что в таком случае множество связей - владельца многозначного атрибута- необходимо превратить во множество сущностей.В случае наличия атрибутивных отображений в декартово произведение мно-жеств значений их надо представлять или элементарными атрибутами, или атри-бутами-агрегатами, или и тем, и другим одновременно.На рис. 3 приведена ER-схема нашей ПрО в нотации Oracle Designer, получен-ная из исходной ER-схемы в нотации Чена.Рис. 3. ER-диаграмма родственных отношений (нотация Oracle Designer)Далее Oracle Designer позволяет автоматически получить из этой схемы реля-ционную схему, приведенную на рис. 4.Как видим, полученный результат ничем не отличается от предыдущего.Рис. 4. Диаграмма реляционной схемы родственных отношений (нотация Oracle Designer)6. ERM-модельЦелью научных исследований автора является совершенствование семантиче-ской методики проектирования схем БД. Результатом этих исследований являетсямодель «Сущность - Связь - Отображение» (раннее название - «Объект - Отобра-жение») [6], которая продолжает развитие ER-модели в сторону более детальногоописания закономерностей ПрО. При этом сохраняются основные, практическивостребованные конструкции, а также вводятся новые, не менее полезные элемен-ты, существенно повышающие выразительные возможности модели. Англоязыч-ное название модели - Entity-Relationship-Mapping Model или ERM-model.Кратко перечислим нововведения.1. Явно введено понятие «класс» как обобщение понятий «множество сущно-стей», «множество связей» и «множество значений». Именно классы образуютобласти определения и области значений отображений.2. Специализации и категоризации подняты на уровень класса, что позволяетрассматривать иерархии обобщения не только множеств сущностей, но также имножеств связей, и множеств значений.3. Введено понятие «отображение». Определение каждого отображения вклю-чает помимо прочего указание ролей образов и прообразов, а также классов, объ-екты которых играют эти роли.4. Выделены частные случаи отображений - атрибутивные и реляционныеотображения. Первые полностью соответствуют аналогам в модели Чена. Вторыеопределяются множествами связей, и в качестве образов и прообразов в них вы-ступают сущности.5. Между отображениями вводятся отношения следствия и эквивалентности.6. Определена алгебра отображений - набор операций, задаваемых на множе-стве отображений. Каждая операция имеет одно или два отображения на входе ипродуцирует одно отображение на выходе.7. Для специализаций введено понятие основания деления. В качестве таково-го выступают отображения.МатьРождениеМуж1ЕМатьMЧеловек ОтецЖенщина МужчинаБракЖена1|||| ||1ЕРебенок1MЕОтецM1Родитель-РебенокЕРебенокМРодительNРис. 5. ERM-диаграмма родственных отношений(расширенная графическая нотация)Ключевым моментом, повлекшим за собой возможности более глубокого ана-лиза ПрО, является дальнейшая декомпозиция понятия «множество связей» (в ER-модели при этом рассматриваются только роли сущностей) и выделение так назы-ваемых семантически значимых отображений. Каждое множество связей степениn определяет 2n − 2 отображений между множествами сущностей.На рис. 5 приведена ERM-схема ПрО родственных отношений.Методика трансляции ERM-схем в реляционную схему для рассматриваемогопримера приводит к схеме с одним единственным отношением ЧЕЛОВЕК(ЧЕЛОВЕК_ID, ФИО, ПОЛ, ОТЕЦ_ID, МАТЬ_ID, СУПРУГ_ID) и следующимиограничениями целостности (нотация SQL):ЧЕЛОВЕК_ID NUMBER(10,0) NOT NULL,ФИО CHARACTER(50) NOT NULL,ПОЛ CHARACTER(10) NOT NULL,ОТЕЦ_ID NUMBER(10,0) NOT NULL,МАТЬ_ID NUMBER(10,0) NOT NULL,СУПРУГ_ID NUMBER(10,0) NULL,PRIMARY KEY (ЧЕЛОВЕК_ID),UNIQUE (СУПРУГ_ID),FOREIGN KEY (ОТЕЦ_ID) REFERENCES ЧЕЛОВЕК (ЧЕЛОВЕК_ID),FOREIGN KEY (МАТЬ_ID) REFERENCES ЧЕЛОВЕК (ЧЕЛОВЕК_ID),FOREIGN KEY (СУПРУГ_ID) REFERENCES ЧЕЛОВЕК (ЧЕЛОВЕК_ID).ЗаключениеПрименение ERM-модели в сочетании с детально проработанными правиламитрансляции схем позволит приблизить семантическую методику проектированияБД к намеченному идеалу. А ее воплощение в CASE-инструменте сведет задачупроектирования к построению ERM-схемы и применению средств автоматическо-го преобразования.Причем в результирующей схеме будут представлены помимо прочего проце-дурные реализации (в виде триггеров) ограничений целостности, выходящих зарамки возможностей декларативных средств реляционной модели, а также опре-деления динамических представлений для виртуальных отношений, соответст-вующих избыточным данным с точки зрения теории проектирования реляцион-ных БД, но представляющих интерес с точки зрения пользователей.

Скачать электронную версию публикации