Описательные средства, применяемые для описания моделей данных логического уровня

 

Модель данных — это некоторая абстракция, которая, будучи приложима к конкретным данным, позволяет пользователям и разработчикам трактовать их уже как информацию, то есть сведения, содержащие не только данные, но и взаимосвязь между ними

 

Различают три уровня логической модели, отличающихся по глубине представления информации о данных:

диаграмма сущность-связь (Entity Relationship Diagram, ERD) - включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи многие-ко-многим и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области.

модель данных, основанная на ключах (Key Based model, KB) - более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области.

полная атрибутивная модель (Fully Attributed model, FA) - наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.

Основные компоненты диаграммы ERWin - это сущности, атрибуты и связи. Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира.

 

Построение модели данных предполагает определение сущностей и атрибутов, т. е. необходимо определить, какая информация будет храниться в конкретной сущности или атрибуте. Сущности должны иметь наименование с четким смысловым значением. Именование сущности существительным в единственном числе облегчает в дальнейшем чтение модели. Фактически имя сущности дается по имени ее экземпляра. Например, Заказчик с атрибутами Номер заказчика, Фамилия заказчика и Адрес заказчика. На уровне физической модели ей может соответствовать таблица Customer с колонками Customer_number, Customer_name и Customer_address.

Для внесения сущности в модель необходимо на уровне логической модели использовать кнопку сущности на панели инструментов (ERWin Toolbox). Щелкнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity Editor, можно вызвать диалог Entity Editor, в котором определяются имя, описание и комментарии сущности.

Каждая сущность должна быть полностью определена с помощью текстового описания в закладке Definition. Закладки Note, Note 2, Note 3, UDP (User Defined Properties - Свойства, определенные пользователем) служат для внесения дополнительных комментариев и определений к сущности. В прежних версиях ERWin закладкам Note2 и Note3 соответствовали окна Query и Sample.

Закладка Definition используется для ввода определения сущности. Эти определения полезны как на логическом уровне, поскольку позволяют понять, что это за объект, так и на физическом уровне, поскольку их можно экспортировать как часть схемы и использовать в реальной БД (CREATE COMMENT on entity_name).

Закладка Note позволяет добавлять дополнительные замечания о сущности, которые не были отражены в определении, введенном в закладке Definition. Здесь можно ввести полезное замечание, описывающее какое-либо бизнес-правило или соглашение по организации диаграммы.

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

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

Для атрибутов первичного ключа в закладке General диалога Attribute Editor необходимо сделать пометку в окне выбора Primary Key.

Закладка Definition позволяет записывать определения отдельных атрибутов. Определения атрибутов можно также сгенерировать как часть схемы (CREATE COMMENT on entity_name.attribute_name). Закладка Note позволяет добавлять замечания об одном или нескольких атрибутах сущности, которые не вошли в определения. Закладка UDP служит для задания значений свойств, определяемых пользователем. Предварительно эти свойства должны быть внесены в диалог User-Defined Property Editor как свойства атрибутов.

Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Согласно синтаксису IDEF1X имя атрибута должно быть уникально в рамках модели.

На практике такое переименование не всегда удобно, поэтому существует возможность отменить эту опцию. В диалоге Unique Name Option (меню Option/Unique Name) можно задать следующие режимы именования атрибутов:

- Allow - позволить внесение одинаковых имен;

- Rename - переименовывать атрибуты (по умолчанию);

- Ask - запрашивать возможные действия каждый раз при внесении одноименных атрибутов. ERWin будет показывать на экране окно-диалог Edit Unique Name каждый раз, когда вводится неуникальное имя сущности или атрибута. В диалоге Edit Unique Name можно ввести другое имя или разрешить дублирование. При этом новое имя не проверяется на уникальность;

- Disallow - запретить внесение одинаковых имен. Если двойное имя обнаружено, то ERWin выдает на экран окно с сообщением, что ввод неуникальных имен запрещается.

Каждый атрибут должен быть определен (закладка Definition).

Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases). Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы, например:

- Каждый КЛИЕНТ <размещает> ЗАКАЗы;

- Каждый ЗАКАЗ <выполняется> СОТРУДНИКом.

Связь показывает, какие именно заказы разместил клиент и какой именно сотрудник выполняет заказ. По умолчанию имя связи на диаграмме не показывается. Для отображения имени следует в контекстном меню диаграммы, выбрать пункт Display Options/Relationship и затем включить опцию Verb Phrase.

На логическом уровне можно установить идентифицирующую связь один-ко-многим, связь многие-ко-многим и неидентифицирующую связь один-ко-многим (соответственно это кнопки слева направо в палитре инструментов).

В IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERWin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами (сущность Заказ на рис. 1). Экземпляр зависимой сущности определяется только через отношение к родительской сущности, т. е. в структуре на рис. 1 информация о заказе не может быть внесена и не имеет смысла без информации о клиенте, который его размещает. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (FK).

Рис. 1. Идентифицирующая связь между независимой и зависимой таблицей

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

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

Экземпляр сущности Заказ может существовать безотносительно к какому-либо экземпляру сущности Автомобиль, т. е. заказ может не перевозиться ни одним автомобилем.

Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи (см. рис. 1), неидентифицирующая - пунктирной (рис. 2).

Для создания новой связи следует:

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

Для редактирования свойств связи следует выбрать в контекстном меню связи пункт Relationship Editor. В закладке General появившегося диалога можно задать мощность, имя и тип связи.

 

 

Принцип QBE

 

QBE (англ. Query by Example, запрос по образцу) — способ создания запросов к базе данных с использованием образцов значений полей в виде текстовой строки. Реализации QBE преобразуют пользовательский ввод в формальный запрос к базе данных, что позволяет пользователю создавать сложные запросы без необходимости изучать более сложные языки запросов, такие как SQL.

Данный метод отбора данных впервые предложен Моше Злуфом (англ. Moshé M. Zloof), сотрудником исследовательского центра IBM в середине 1970-х годов.

Эксплуатационным преимуществом поиска QBE является то, что для формирования запроса не требуется использовать специализированный язык запросов, синтаксис которого может быть сложен и недоступен конечному пользователю. Пользователю выводится окно, в котором указаны все поля данных, встречающиеся в каждой записи данных; введение информации в конкретное поисковое поле ограничит поиск совпадением (полным или частичным, в зависимости от договорённости реализации) по данному полю. Проверка условий осуществляется только по заполненным условиям на поля, а поля, условия на которые указаны не будут, могут соответствовать чему угодно. Многие практические реализации QBE допускают также не только конъюнктивное соединение условий в заполненных полях, но и другие варианты соединения условий (например, дизъюнкцию, отрицание, существование или несуществование связанных записей и другие).

Теоретической основой языка QBE является реляционное исчисление с переменными-доменами (однако в языке присутствуют и элементы исчисления кортежей).

Язык QBE позволяет задавать сложные запросы к БД путем заполнения предлагаемой СУБД запросной формы (иногда также используют термин QBЕ – запрос по форме).

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

В каждой из современных реляционных СУБД имеется свой вариант языка QBE.

На языке QBE можно задавать однотабличные и многотабличные (выбирающие или обрабатывающие данные из нескольких связанных таблиц) запросы.

С помощью запросов на языке QBE можно выполнять следующие основные операции:

· выборку данных;

· вычисление над данными;

· вставку новых записей;

· удаление записей;

· модификацию (изменение) данных.

Результатом выполнения запроса является новая таблица, называемая ответной (первые две операции), или обновленная исходная таблица (остальные операции). В реальных приложениях баз данных QBE используется в основном для выборки данных.

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

Запросная форма обычно имеет вид таблицы, имя и названия полей которой совпадают с именем и названиями полей соответствующей исходной

таблицы. Чтобы узнать имена доступных таблиц БД, в языке QBE предусмотрен запрос на выборку имен таблиц. Названия полей исходной таблицы могут вводиться в шаблон вручную или автоматически. Во втором случае используется запрос на выборку заголовков столбцов.

В современных СУБД, например, в Access и Visual FoxPro, многие действия по подготовке запросов с помощью языка QBE выполняются визуально с помощью мыши. В частности, визуальное связывание таблиц при подготовке запроса выполняется не элементами примеров, а просто «протаскиванием» мышью поля одной таблицы к полю другой.

По возможностям манипулирования данными при описании запросов указанные языки практически эквивалентны. Более того, на практике запрос, составленный на QBE, обычно транслируется в SQL – запрос и лишь затем выполняется.

Главное отличие между данными языками заключается в способе формирования запросов: язык QBE предполагает ручное или визуальное формирование запроса, в то время как использование SQL означает программирование запроса