Экзаменационный билет n 13

1. Языковые средства СУБД.

Языковые средства СУБД являются важнейшим компонентом банков данных, так как, в конечном счете, они обеспечивают интерфейс пользователей разных категорий с банком данных. Набор используемых языковых средств широк и разнообразен. Языковые средства, используемые в БнД, можно классифицировать по разным признакам (рис. 1.6).

Языковые средства большинства современных СУБД относятся к языкам 4-го поколения (к 1-му поколению языков относят машинные языки, ко 2-му - символические языки ассемблера, к 3-му - алгоритмические языки типа PL, Cobol и т.п., которые в 1960-е гг. назывались языками высокого уровня, но уровень, которых гораздо ниже, чем у языков 4-го поколения. Имеются еще и языки 5-го поколения, к которым относят языки систем искусственного интеллекта, например Prolog).

Рис. 1.6. Классификация языковых средств БнД

Можно выделить две концепции развития языковых средств: концепцию разделения и концепцию интеграции. При использовании концепции разделения различают языки описания данных (ЯОД) и языки манипулирования данными (ЯМД). Назначение каждого из этих подклассов ясно из их названия.

Иногда в особую группу выделяют языки запросов (ЯЗ). Первоначально под языками запросов понимали языки высокого уровня, ориентированные на конечного пользователя, предназначенные для формирования запросов к БД (в такой трактовке их можно считать одной из разновидностей ЯМД). Однако сейчас ЯЗ понимается шире (см. главу 3); многие ЯЗ включают в себя еще и возможности описания данных и корректировки БД.

В составе языков описания данных в зависимости от особенностей СУБД поддерживаются все или некоторые из следующих языков: язык описания схем (ЯОС), язык описания подсхем (ЯОПС), язык описания хранимых данных (ЯОХД), языки описания внешних данных (входных, выходных). В некоторых СУБД и сами эти разновидности языков, и создаваемые с их помощью элементы ИС являются самостоятельными компонентами, в других - некоторые из них могут быть объединены.

Языки манипулирования данными разделяются на две большие группы: процедурные и непроцедурные (декларативные). При пользовании процедурными языками надо указать, какие действия и над какими объектами необходимо выполнить, чтобы получить результат. В непроцедурных языках указывается, что надо получить в ответе, а не как этого достичь.

Процедурные языки могут различаться по основным информационным единицам, которыми они манипулируют. Это могут быть языки, ориентированные на позаписную обработку данных, и языки, ориентированные на операции над множеством записей. Так, операции реляционной алгебры оперируют целиком отношением, а не каждой его записью. Примерами непроцедурных языков являются языки, основанные на реляционном исчислении. К таким языкам относится широко используемый язык запросов SQL. Табличный язык QBE также является непроцедурным языком.

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

По функциональным возможностям выделяют следующие категории языков [44].

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

2. Комплексные языки запросов/обновлений. Это более развитые языки; они позволяют формулировать сложные запросы, относящиеся к нескольким взаимосвязанным записям, и обновлять данные так же легко, как и формулировать запросы. Используя их, пользователи могут создавать свои собственные файлы.

3. Генераторы отчетов. Они дают возможность выбирать нужные данные из файлов или баз данных и форматировать их в виде требуемых форм документов.

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

5. Инструментальные средства поддержки решений. Языки этого типа предназначены для создания систем принятия решений. Это могут быть системы типа «что-если», системы, выполняющие временной или трендовый анализ, и др. Возможно использование как универсальных, так и проблемно-ориентированных средств.

6. Генераторы приложений. Обеспечивают возможность описания непроцедурным путем требуемой обработки информации и дальнейшей автоматической генерации программ.

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

8. Языки очень высокого уровня. В большинстве случаев приложения строятся с помощью непроцедурных языков. Однако некоторые языки являются процедурными (например, NOMAD), но программирование на них значительно короче, чем, например, на Cobol.

9. Параметризированные пакеты прикладных программ (ППП). Эта категория программных средств известна давно, и «4-е поколение» относится к таким ППП, которые допускают легкую модификацию самого пакета, позволяют пользователям генерировать собственные отчеты, запросы к базе данных и т.д.

10. Языки приложений. Многие языки 4-го поколения являются универсальными, другие - спроектированы для специфических приложений. Примерами таких языков являются языки для управления финансами, управления работой станков с программным управлени­ем и т.д.

По форме представления различают аналитические, табличные и графические языковые средства. Классификация языковых средств по этому признаку относится как к языкам описания данных, так и к языкам манипулирования данными. Так, описание таблицы с использованием команды CREATE TABLE языка SQL (см. главу 7) является примером аналитической формы ЯОД, а описание такой же таблицы в Access (см. главу 5) и большинстве других настольных СУБД - примером табличной формы описания данных. В качестве примеров табличной и аналитической форм задания запросов можно привести языки QBE (см. главу 6) и SQL (см. главу 7) соответственно.

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

2. Виды связей между объектами и их отражение в даталогической модели.

Связи между объектами также должны отражаться в структуре БД. Универсальный способ отображения связи между объектами - введение вспомогательного связующего файла, содержащего идентификаторы связанных объектов. Ключ этого отношения будет составным. Такое решение является практически единственно приемлемым при наличии связи М:М между объектами. Дополнительный довод в пользу такого решения - наличие необязательного класса членства объекта в связи. Во многих случаях можно использовать другие, более эффективные способы отображения связей в структуре БД. Выбор проектного решения прежде всего будет зависеть от типа связи между объектами.

Отображение связи типа М:М. Если между объектами предметной области имеется связь М:М, то для хранения такой информации потребуются три отношения: по одному для каждой сущности и одно дополнительное - для отображения связи между ними. Последнее отношение будет содержать идентификаторы связанных объектов (рис. 3.2). Ключ этого отношения будет составным.

Рис. 3.2. Отображение связи М:М: а - фрагмент ER-модели;

б - реляционные таблицы

Отображение связи типа 1:М. Если между объектами предметной области имеется связь 1:М, то можно, так же как и в случае связи М:М, использовать отдельную связующую таблицу (рис. 3.3, б - вариант 2). В отличие от связи М:М ключом связующей таблицы будет только идентификатор объекта, к которому направлен единичный конец связи.

Однако если между объектами предметной области имеется связь 1:М и класс принадлежности n-связной сущности является обязательным, то можно использовать только два отношения (по одному для каждой сущности) и не использовать дополнительную связующую таблицу. В отношение, соответствующее 1-связной сущности (т.е. сущности, к которой идет единичная связь), нужно дополнительно добавить идентификатор связанного с ней объекта (рис. 3.3, б - вариант 1).

Рис. 3.3. Отображение связи 1:М: а - фрагмент ER-модели;

б - реляционные таблицы

Отображение связи типа 1:1. Наличие между объектами связи типа 1:1 является довольно-таки редкой ситуацией в реальной жизни. В принципе, если связь между объектами 1:1 и класс принадлежности обеих сущностей является обязательным, для отображения обоих объектов и связи между ними можно использовать одну таблицу (рис. 3.4, б - вариант 3). Такое решение потребует меньше всего памяти для своей реализации. Например, если имеются объекты СОТРУДНИК и ПАСПОРТ, то такое решение будет вполне приемлемым. Однако таким решением не следует злоупотреблять. Может случиться, что для каждого объекта, находящегося в связи 1:1, в дальнейшем понадобится отразить какие-то свои связи или в запросах потребуется информация отдельно по каждому из объектов. Тогда выбранное решение может усложнить или замедлить работу с БД.

Рис. 3.4. Отображение связи 1:1: а - фрагмент ER-модели;

б - реляционные таблицы

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

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

Если степень связи между объектами равна 1:1 и класс принадлежности каждого из них является необязательным, то, чтобы избежать наличия пустых полей, следует использовать три отношения: по одному для каждой сущности и одно - для отображения связи между ними (рис. 3.4, б - вариант 4). В приведенном решении в качестве ключа связующей таблицы обозначен ИО1. С таким же успехом мог быть выбран ИО2.

Отображение альтернативной связи. Альтернативная связь обычно используется при изображении агрегированного объекта и означает, что в действии участвует либо один объект, либо другой, но не оба вместе. Альтернативная связь трудна для ее «автоматического» преобразования в даталогическую модель. Может быть, поэтому она отсутствует в большинстве CASE-средств.

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

Другой вариант решения: для отражения связи с каждым из альтернативных классов объектов использовать отдельную таблицу.

Часто объекты, объединенные альтернативной связью, по сути, являются подклассами обобщенного класса. Иногда имеет смысл по-иному изобразить ER-модель, чтобы увидеть другие варианты проектных решений.

Дата добавления: 2015-04-24