С.Д. Кузнецов - Основы баз данных (1121716), страница 33
Текст из файла (страница 33)
Подавляющее большинство подобных систем, представленных на рынке, обеспечивает автоматизированное преобразование диаграммных концептуальных схем баз данных, представленных в той или иной семантической модели данных, в реляционные схемы, специфицированные чаше всего на языке Я(.)Е, У читателя может возникнуть вопрос, почему в предыдушем предложении говорится про «автоматизированное», а не про «автоматическое» преобразование? Все дело в том, что в типичной схеме Я()Е-ориентированной БД могут содержаться определения многих объектов (ограничений целостности обшего в разных областях промышленности — автомобилестроении, аэрокосмической промышленности, электронной промышленности и тл.
Очевидно, что процесс проектирования автомобиля принципиально отличается от процесса проектирования микропроцессора, но, тем не менее, для обозначения любой Системы Автоматизации ПРоектирования используется собирательный термин САПР (САП вЂ” Сошршег Амеб Гзеащп). это оправдывается тем, что разные подклассы САПР имеют гораздо больше общих черт, чем различий.
Так вот, по моему мнению, система автоматизации проектирования БД по своему назначению и строению в большей степени является системой класса САПР, чем системой класса САБЕ (Сошрщег Амеб Бойнаге Епй!пееппа). По всей видимости, средства автоматизированной поддержки проектирования баз данных стали в свое время называть САБЕ- средствами, поскольку они обычно включали не только инструменты дхя поддержки проектирования, но и инструменты, поддерживающие проектирование и разработку приложений баз данных. В последние годы такие инструменты все реже производятся в аиде одного пакета, и сам термин «САБЕ-средство» почти вышел из употребления. Тем не менее, поскольку не появилось какое-либо другое собирательное название средств поддержки проектирования баз данных, мы будем продолжать испольэовать именно зтог термин. 188 Лекция 9 Ей-диаграммы вида, триггеров и хранимых процедур и т.
д.), которые невозможно сгенерировать автоматически на основе концептуальной схемы. Поэтому на завершающем этапе проектирования реляционной схемы снова требуется ручная работа проектировщика. Еще раз обратите внимание на то, какой ход рассуждений привел нас к выводу о возможности автоматизации процесса преобразования концептуальной схемы БД в реляционную схему. Если создатели семантической модели данных предоставляют методику преобразования концептуальных схем в реляционные, то почему бы не реализовать программу, которая производит те же преобразования, следуя той же методике? Зададимся теперь другим, но, по существу схожим вопросом. Если создатели семантической модели данных предоставиют язык (например, диаграммный), используя который проектировщики БД на основе исходной информации о предметной области могут сформировать концептуальную схему БД, то почему бы не реализовать программу, которая сама генерирует концептуальную схему БД в соответствующей семантической модели, используя исходную информацию о предметной области? Хотя нам не известны коммерческие САБЕ- средства проектирования БД, поддерживающие такой подход, экспериментальные системы успешно существовали.
Они представляли собой интегрированные системы проектирования с автоматизированным созданием концептуальной схемы на основе интервью с экспертами предметной области и последующим преобразованием концептуальной схемы в реляционную. Как правило, САБЕ-средства, автоматизирующие преобразование концептуальной схемы БД в реляционную, производят реляционную схему базы данных в третьей нормальной форме. Нормализация более высокого уровня усложняет программную реализацию и редко требуется на практике.
Наконец, третья возможность, которую следует упомянуть, хотя она еще не вышла (или только выходит, а может быть, так никогда и не выйдет) за пределы исследовательских и экспериментальных проектов, — это работа с базой данных в семантической модели, т. е. СУБД, основанные на семантических моделях данных. При этом снова рассматриваются два варианта: обеспечение пользовательского интерфейса на основе семантической модели данных с автоматическим отображением конструкций этого интерфейса в реляционную модель данных (это задача примерно того же уровня сложности, что и автоматическая компиляция концептуальной схемы базы данных в реляционную схему) и прямая реализация СУБД, основанная на какой-либо семантической модели данных.
Многие авторитетные специалисты полагают, что ближе всего ко второму подходу объектно-ориентированные СУБД, чьи модели данных по многим параметрам близки к семантическим моделям (хотя в некоторых аспектах они более мощны, а в некоторых — более слабы). 159 Основы бвз данных Курс Семантическая модель ЕпШу-йе!аМопвЫр (Сущность-Связь) В этой лекции мы кратко рассмотрим некоторые черты одной из наиболее популярных семантических моделей данных — модели «СушностьСвязь» (часто ее называют кратко ЕК-моделью от Епг(гу-йе)агсопвп(р). Здесь следует сделать два замечания, касающиеся, главным образом, терминологии.
Оба термина ге!ассоп и ге!ассопз1ир могут быть переведены на русский язык как отношение. Поэтому в русскоязычной литературе ЕК-модель иногда называют моделью сущность-отношение, а иногда и реляционной семантической моделью. Наверное, в этом нет ничего страшного, если говорить о ЕК-модели в отрыве от тематики проектирования реляционных баз данных. Но если требуется одновременно использовать термины ЕК-модели и реляционной модели данных, то, безусловно, требуется применять для терминов ге(аг(оп и ге!аг(опвпср разные русские эквиваленты.
За этими терминами стоят весьма различные понятия. В реляционной модели отношение (ге1агюп) — это единственная родовая структура данных. С помошью этого же механизма представляются «связанные» сущности (вспомните, например, про внешние ключи). Как мы увидим немного позже, в ЕК-модели для представления схемы базы данных используются два равноправных понятия — сущность и связь. Связи в ЕК-модели играют роль, отличную от той, какую играют отношения в реляционной модели данных. Кроме того, в русскоязычную терминологию вошла и чистая транслитерация термина ге)агсоп именно в смысле отношение. Мы говорим, например, про реляционную модель данных, реляционную алгебру и т. д., понимая модель данных„основанную на отношениях, алгебру отношений и т.
п. Поэтому поводу, по крайней мере, в контексте баз данных, разумно окончательно зарезервировать термины Ыагсоп и отношение для обозначения понятий реляционной модели данных, а для термина св!агсопвпср использовать другой допустимый русскоязычный эквивалент — связь. На использовании разных вариантов ЕК-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных).
Модель была предложена Питером Ченом (Регег Озеп) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включаюших небольшое число разнородных компонентов. Простота и наглядность представления концептуальных схем баз данных в ЕК-модели привели к ее широкому распространению в САЯЕ-системах, поддерживаюших автоматизированное проектирование реляционных баз данных. Среди множества разновидностей ЕК-моделей одна из наиболее популярных и развитых применялась в системе САЯЕ компании 1БО Лекция 9 Ей-диаграммы Огас1е. Мы обсудим некоторый упрощенный вариант этой модели. Если говорить более точно, сосредоточимся на ее структурной и целостной частях. Основные понятия Ей-модели Основными понятиями ЕВ-модели являю я сущноспзь, связь и атрибут.
Сущносгпь — это реальный или представляемый объект, информация о котором должна сохраняться и быть доступной.* В диаграммах ЕВ-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности — это имя типа, а не некоторого конкретного экземпляра этого типа.'* Для большей выразительности и лучшего понимания имя сущности может сопровождаться примерами конкретных экземпляров этою типа.
Рис. 9.1. Пример типа сущности На рис. 9.1 изображена сущность АЭРОПОРТ с примерными экземплярами «Шереметьево» и «Хитроу»». Эта примитивная диаграмма тем не менее несет важную информацию. Во-первых, она показывает, что в базе данных будут содержаться однотипные структуры данных (экземпляры сущности), описывающие аэропорты.
Во-вторых, поскольку в жизни существует несколько точек зрения на аэропорты (например, точка зрения пилота, точка зрения пассажира, точка зрения администратора) и этим точкам зрения соответствуют разные структуры данных, то приведенные примеры аэропортов позволяют несколько сузить допустимый набор точек зрения. В нашем случае приведены примеры международных аэропортов, так что, скорее всего, имеется точка зрения пассажира или пилота международных авиарейсов. ' Понятно, что это «определение» на самом леле явяяется тавтологией, поскольку во-первых, мы и»наемся определить термин сущность через не определенный термин абаект, а во-вторых, попьпки определения термина абьект настолько же безнадежны.
Обычно авторы пытаются оправдываться тем, что в подобном контексте они имеют в виду «жнтейское», а не сколько-нибудь формазизованное понятие абзекта. Конечно, от этого не становится яегче, поскольку понятие сущности должно пониматься в достаточно точном смысле. Но зта тавтология не изобретена автором этого курса; она традиционна для области семантического моделирования. В этой области стремятся максимально избегать формальностей. "* Хотя было бы правильнее всегда использовать термины тин сущности и зкзеипир тина сущности, для избежания мнопюловносзн (и следуя традиции) в тех случаях, где это не приводит к двусмысленности, мы будем использовать термин сущность в значении тина сущности. тбт Основы баз данных При определении типа сущности необходимо гарантировать, что каждый экземпляр сущности может быть отличим от любого другого экземпляра той же сущности.
Это требование в некотором роде аналогично требованию отсутствия кортежей-дубликатов в реляционных таблицах. Связь — это графически изображаемая ассоциация, устанавливаемая между двумя типами сущностей. Как и сущность, связь — это типовое понятие, все экземпляры обоих связываемых типов сущностей подчиняются устанавливаемым правилам связывания. Поэтому правильнее говорить о типе связи, устанавливаемой между типами сущности, и об экземплярах типа связи, устанавливаемых между экземплярами типа сущности.* В обсуждаемом здесь варианте ЕВ-модели эта ассоциация всегда является бинарной и может существовать между двумя разными типами сущностей или между типом сущности и им же самим (рекурсивная связь).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
