Шпаргалка по "Информатике"

5. Правило полноты языка  работы с данными. Сколько бы  много в СУБД ни поддерживалось  языков и режимов работы с  данными, должен иметься по  крайней мере один язык, выразимый  в виде командных строк в  некотором удобном синтаксисе, который  бы позволял формулировать: 

• определение данных,
• определение правил целостности,
• манипулирование данными (в диалоге и из программы),
• определение выводимых таблиц (в том числе возможности их модификации),
• определение правил авторизации,
• границы транзакций.

6. Правило модификации  таблиц-представлений. В СУБД  должен существовать корректный  алгоритм, позволяющий автоматически  для каждой таблицы-представления  определять во время ее создания, может ли она использоваться  для вставки и удаления строк  и какие из столбцов допускают  модификацию, и заносящий полученную  таким образом информацию в  системный каталог.

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

8. Правило физической  независимости. Диалоговые операторы  и прикладные программы на  логическом уровне не должны  страдать от каких-либо изменений  во внутреннем хранении данных  или в методах доступа СУБД.

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

10. Правило сохранения  целостности. Диалоговые операторы  и прикладные программы не  должны изменяться при изменении  правил целостности в БД (задаваемых  языком работы с данными и  хранимых в системном каталоге).

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

12. Правило ненарушения  реляционного языка. Если в  реляционной СУБД имеется язык  низкого уровня (для работы с  отдельными строками), он не должен  позволять нарушать или "обходить" правила, сформулированные на  языке высокого уровня (множественном)  и занесенные в системный каталог.

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

Другие модели

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

Моделью данных, привлекающей нарастающее внимание с конца 80-х  гг., является объектная, или "объектно-ориентированная"(3) модель (см., например, одну из первых работ [5]). Основными понятиями, с которыми оперирует эта модель, являются следующие:

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

К достоинствам объектно-ориентированной  модели обычно относят:

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

К недостаткам объектно-ориентированной  модели можно отнести:

• отсутствие строгих определений; разное понимание терминов и различия в терминологии (в [7], например, изъявляется готовность изложить восемь различных толкований такого базового понятия, как "наследуемость");
• как следствие - эта модель не исследована столь тщательно математически, как реляционная;
• отсутствие общеупотребимых стандартов, позволяющих связывать конкретные объектно-ориентированные системы с другими системами работы с данными.

Некоторые специалисты основным и главным отличием объектно-ориентированной  модели от реляционной считают наличие  уникального системного идентификатора(4). Эта разница связана с одним интересным семантическим явлением. Дело в том, что в реляционной модели объект целиком описывается его атрибутами. Если человек в таблице представлен именем и номером телефона, то что происходит после замены номера телефона в существующей строке ? Идет ли после этого речь о том же самом человеке или о другом ? В реляционной модели нет средств получить ответ на этот вопрос; в объектно-ориентированной его дает неизменившийся системный идентификатор. С другой стороны, мы можем "заменить" в базе данных одного сотрудника на другого, сохранив все связи и атрибуты прежнего, и при этом системный идентификатор не изменится. Ясно, однако, что подразумеваться будет совсем другой человек.

Еще одной моделью данных, имеющей конкретную реализацию (система InfoModeller), является модель "объектов-ролей", предложенная еще в начале 70-х  годов, однако выведенная за рамки академических  исследований совсем недавно коллективом  фирмы Asymetrix [5]. В отличие от реляционной модели в ней нет атрибутов, а основные понятия - это объекты и роли, описывающие их. Роли могут быть как "изолированные", присущие исключительно какому-нибудь объекту, так и существующие как элемент какого-либо отношения между объектами. Модель, по словам авторов, служит для понятийного моделирования, что отличает ее от реляционной модели. Имеются и другие отличия и интересные особенности: например, для нее помимо графического языка разработано подмножество естественного языка, не допускающее неоднозначностей, и, таким образом, пользователь (заказчик) не только общается с аналитиком на естественном языке, но и видит представленный на том же языке результат его работы по формализации задачи. (Можно заметить, что многие пользователи, в отличие от аналитиков, с трудом разбираются в описывающих их деятельность рисунках и схемах.) Модель "объектов-ролей" сейчас привлекает большое внимание специалистов, однако до промышленных масштабов ее использования, сравнимых с двумя предыдущими, ей пока далеко.

Взаимосвязь моделей данных

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

Много дебатов, к примеру, ведется по вопросу, совместимы ли и  если да, то каким образом, реляционная  и объектная модели. Существуют мнения, что они взаимоисключают друг друга и что они взаимодополняют  друг друга. Последнего придерживается, например, такой авторитет в области  теории баз данных, как К.Дейт [7]. Согласно Дейту синергия двух моделей могла бы ("должна" - по утверждению автора) базироваться на формуле "область определения атрибута = класс объектов". Иными словами, атрибутами в реляционных таблицах могут быть объекты произвольно заданной сложности. С точки зрения реляционной модели они остаются атомарными, а все возможности работы с ними, проистекающие из наличия внутренней структуры, реализуются объектно-ориентированными методами. Существует выбор, какие свойства предметной области моделировать реляционными методами (т.е. моделировать таблицами, связанными друг с другом ключами), а какие - объектными, но это уже составляет проблему разработчика базы данных: теория здесь лишь предоставляет возможности такого выбора. Предложение Дейта не противоречит ни реляционному, ни объектному подходу и выглядит теоретически обоснованным. В то же время оно противоречит другому подходу, основывающемуся на формуле "класс объектов = таблица", когда с объектом связывается строка таблицы. Этот подход получил распространение в практике производителей объектно-ориентированных СУБД.

Другой аспект взаимной связи  указанных двух моделей носит  реализационный характер. Некоторые  объектно-ориентированные системы  сами реализованы на "реляционно-ориентированных" СУБД, как на системах, получивших доминирующее распространение на рынке СУБД, и  вследствие этого наиболее продвинутых  как промышленные изделия. В таких  системах определения, заданные в рамках объектного подхода, переводятся в  реляционные определения, или наоборот, объектно-ориентированные определения  строятся как надстройки над реляционно-ориентированными системами.

Переход от модели "объекты-роли" к реляционной заложен создателями  в основу реализации первой. Модель "объекты-роли" согласно такой  позиции рассматривается как  понятийная, а реляционная модель - как реализационная. Трансформация  определений "объектов-ролей" в  реляционные определения не просто возможна, а и изначально предположена в InfoModeller, причем гарантируется высокое качество результата такого преобразования: получаемые таблицы имеют так называемую "5-ую нормальную форму", считающуюся более качественной в реляционном плане, чем обычно требуемая в реляционных СУБД "3-я нормальная форма".

3. Проектирование логической  структуры БД, создание и использование  БД

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

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

Последним этапом проектирования является построение логической структуры  БД. Структура реляционной БД Access является адекватным отображением полученной информационно – логической модели предметной области, но требует дополнительных преобразований.

Каждый информационный объект модели данных отображается соответствующей  реляционной таблицей. Структура  таблиц определяется составом атрибутов  соответствующего информационного  объекта, где каждое поле (столбец) соответствует  одному атрибуту объекта.

Ключевые атрибуты объекта  образуют уникальный ключ реляционной  таблицы. Строки (записи) таблицы соответствуют  экземплярам объекта и формируются  при заполнении таблицы.

Связи между объектами  реализуются одинаковыми атрибутами – ключами связи в соответствующих таблицах. При этом ключом связи всегда является уникальный ключ главной таблицы. Ключом связи в подчинённой таблице является либо некоторая часть уникального ключа в ней, либо поле, не входящее в состав первичного ключа.

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