Актуальность. Бычкова С.М. Аудиторская деятельность

Бычкова С.М. Аудиторская деятельность. Теория и практика.СПб.:Лань,2000.С.320.

Смолянский А. Развитие новых методов аудита. //Аудит, 1998, №6.

Воронина В.М. Основы бухучета и аудита. Уч. пос. в 2-х частях, ч.2, М.: 1997.

Аудит. Уч. для ВУЗов / под ред. Подольского М., Аудит, ЮНИТИ, М.:1997.

Богомолов А.М. Голощаков Н.А. Внутренний аудит. Организация и методика проведения: метод.пос. М.:Экзамен, 1999.

Шеремет А.Л. Суйц В.П. Аудит: уч.пос. М.:ИНФРА-М, 1995.

 

 

ТЕКСТ ЛЕКЦИИ №5

По дисциплине

«Современные системы управления базами данных»

 

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

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

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

 

Тема 3. Модели данных

ДАТАЛОГИЧЕСКИЕ МОДЕЛИ ДАННЫХ

Учебные вопросы

Иерархическая и сетевая модели данных.

Реляционная модель данных.

Сравнительный анализ даталогических моделей.

 

Задание на самоподготовку: [1], с.94-124

 

Время: 90 минут

 

Место: ауд._____

 

Материальное обеспечение и наглядные пособия

1. Графопроектор.

2. Диапроектор.

3. Комплект слайдов и диапозитивов.

4. Стенды лекционной аудитории.

 

I. ВВОДНАЯ ЧАСТЬ (»15 мин.)

Учебный поток в лекционной аудитории

15¢

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

 

Правила и меры безопасности

 

1. Операции с ТСО выполняет дежурный по группе только по командам преподавателя.

2. Пользование другими электроприемниками на занятиях запрещено.

 

Вопросы контроля

1. Схематически представить на доске жизненный цикл информационной системы, основанной на базе данных.

2. Схематически представить на доске и пояснить трехуровневую модель представления данных.

3. Дать определение БД, указать цели и подходы к проектированию БД.

4. АБД. Функции администратора базы данных.

5. Привести классификацию пользователей баз данных.

 

Актуальность

Вычислительная техника с каждым годом все шире применяется в различных сферах человеческой деятельности. Это объясняется рядом объективных причин. Прежде всего, следует отметить успехи как в области технического, так и математического обеспечения ЭВМ, в развитии электроники и интегральной схемотехники. Современные вычислительные машины и системы достигли высокого уровня развития.

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

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

Резкий рост объемов перерабатываемой информации и накопленный опыт использования электронно-вычислительной техники в военной сфере приводят к необходимости пересматривать такую традиционную область обработки информации, как управление данными.

II. ОСНОВНАЯ ЧАСТЬ (»70 мин)

Основным содержанием сегодняшней лекции является рассмотрение вопросов даталогического уровня в общей архитектуре представления данных.

Модель данных – фиксированная система понятий и правил для представления структуры данных, состояния и динамики проблемной области в базах данных. Как правило, задается языком определения данных и языком манипулирования данными. Примерами модели данных, получившими широкое распространение, являются модели данных сетевая, иерархическая, реляционная и др.

Модель данных состоит из трех компонент.

1. Структура данных для представления точки зрения пользователя на базу данных.
2. Допустимые операции, выполняемые на структуре данных. Они составляют основу языка данных рассматриваемой модели данных. Одной лишь хорошей структуры данных недостаточно. Необходимо иметь возможность работать с этой структурой при помощи различных операций языка определения данных и языка манипулирования данными. Богатая структура данных ничего не стоит, если нет возможности оперировать ее содержимым.
3. Ограничения для контроля целостности. Модель данных должна быть обеспечена средствами, позволяющими сохранять ее целостность и защищать ее.

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

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

1.

2. Иерархическая и сетевая модели данных (»25 мин).

 

Предшественницами СУБД были файловые системы, обладающие существенными недостатками. Однако появление СУБД не привело к полному исчезновению файловых систем. Для выполнения некоторых специализированных задач подобные файловые системы ис­пользуются до сих пор. Считается, что развитие СУБД началось еще в 60-е годы, ко­гда разрабатывался проект полета корабля Apollo на Луну. Этот проект был начат по инициативе президента США Дж.Ф.Кеннеди, поставившего задачу высадить чело­века на Луну к концу десятилетия. В то время не существовало никаких систем, способных обрабатывать или как-либо управлять тем огромным количеством данных, которое было необходимо для реализации этого проекта.

В результате специалисты основного подрядчика — фирмы North American Aviation (теперь эта фирма называется Rockwell International) — разработали про­граммное обеспечение под названием GUAM (Generalized Update Access Method). Основная идея GUAM была построена на том, что малые компоненты объединяют­ся вместе как части более крупных компонентов до тех пор, пока не будет собран воедино весь проект. Эта соответствующая инвертированному дереву структура часто называется иерархической структурой (hierarchical structure). В середине 60-х годов корпорация IBM присоединилась к фирме NAA для совместной работы над GUAM, в результате чего была создана система IMS (Information Management System). Причина, по которой корпорация IBM ограничила функциональные воз­можности IMS только управлением иерархиями записей, заключалась в том, что необходимо было обеспечить работу с устройствами хранения с последовательным доступом, а именно с магнитными лентами, которые были основным типом носи­теля в то время. Спустя некоторое время это ограничение удалось преодолеть. Не­смотря на то, что IMS является самой первой из всех коммерческих СУБД, она до сих пор остается основной иерархической СУБД, используемой на большинстве крупных мейнфреймов.

Иерархическая модель

Иерархическая БД состоит из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева.

Тип дерева состоит из одного «корневого» типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждое из которых является некоторым типом дерева). Тип дерева в целом представляет собой иерархически организованный набор типов записи.

Пример типа дерева (схемы иерархической БД) представлен на слайде №5.1.

 

 

Рис.5.1. Пример схемы иерархической БД

На слайде №5.1 ОТДЕЛ является предком для НАЧАЛЬНИК и СОТРУДНИКИ, а НАЧАЛЬНИК и СОТРУДНИКИ - потомки ОТДЕЛ. Между типами записи поддерживаются связи.

База данных с такой схемой могла бы выглядеть следующим образом (слайд №5.1, показан один экземпляр дерева).

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

Примерами типичных операторов манипулирования иерархически организованными данными могут быть следующие.

· Найти указанное дерево БД (например, отдел 310).

· Перейти от одного дерева к другому.

· Перейти от одной записи к другой внутри дерева (например, от отдела – к первому сотруднику).

· Перейти от одной записи к другой в порядке обхода иерархии.

· Вставить новую запись в указанную позицию.

· Удалить текущую запись.

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

В иерархических системах поддерживалась некоторая форма представлений БД на основе ограничения иерархии. Примером представления приведенной выше БД может быть следующая иерархия (слайд №5.1).

Экземпляр дерева базы данных не обязательно должен содержать все свои сегменты. При необходимости можно добавлять или удалять экземпляры типов записей в соответствии с требованиями приложения.

Иерархическая структура реализует отношение ОДИН-КО-МНОГИМ между исходным и порожденным типами записей. Это отображение полностью функционально, т.к. дерево не может содержать порожденный узел без исходного узла (за исключением «корня»). Следовательно, отображения ОДИН-К-ОДНОМУ и ОДИН-КО-МНОГИМ могут непосредственно представляться иерархическими структурами. Однако для представления отображения МНОГИЕ-КО-МНОГИМ необходимо дублирование деревьев, а значит, реализация сложных связей требует больших затрат памяти.

Другой проблемой иерархий является невозможность хранения в БД порожденного узла без соответствующего исходного, т.е. в этом случае необходимо ввести пустой исходный узел. Соответственно удаление данного исходного узла влечет удаление всех порожденных узлов (поддеревьев), связанных в ним. Эти ограничения создают проблемы применения иерархической модели для некоторых приложений.

 

Следующим заметным достижением середины 60-х годов было появление системы IDS (Integrated Data Store) фирмы General Electric. Работу над ней возглавлял один из пионеров исследований в области систем управления базами данных — Чарльз Бачман (Charles Bachmann). Развитие этой системы привело к созданию нового типа сис­тем управления базами данных — сетевых (network) СУБД, — что оказало сущест­венное влияние на информационные системы того поколения. Сетевая СУБД созда­валась для представления более сложных взаимосвязей между данными, чем те, которые можно было моделировать с помощью иерархических структур, а также для формирования стандарта баз данных. Для создания таких стандартов в 1965 году на конференции организацииCODASYL (Conference on Data Systems Languages), прохо­дившей при участии представителей правительства США и бизнесменов, была сфор­мирована рабочая группа List Processing Task Force, переименованная в 1967 году в группуData Base Task Group (DBTG). В компетенцию группы DBTG входило опреде­ление спецификаций среды, которая допускала бы разработку баз данных и управле­ние данными. Предварительный вариант отчета этой группы был опубликован в 1969 году, а первый полный вариант — в 1971 году. Предложения группы DBTG содер­жали три компонента.

1. Сетеваясхема — это логическая организация всей базы данных в целом (с точки зрения АДБ), которая включает определение имени базы данных, типа каждой записи и компонентов записей каждого типа.

2. Подсхема — это часть базы данных, как она видится пользователям или приложениям.

3. Язык управления данными — инструмент для определения характеристик и структуры данных, а также для управления ими.

Группа DBTG также предложила стандартизировать три различных языка.

1. Язык определения данных (Data Definition Language —DDL) для схемы, который позволит АБД описать ее.

2. Язык определения данных (такжеDDL) для подсхемы, который позволит оп­ределять в приложениях те части базы данных, доступ к которым будет необ­ходим.

3. Язык манипулирования данными (Data Manipulation Language —DML), предназначенный для управления данными.

Несмотря на то, что этот отчет официально не был одобрен Национальным Инсти­тутом Стандартизации США (American National Standards Institute — ANSI), боль­шое количество систем было разработано в полном соответствии с этими предложе­ниями группы DBTG. Теперь они называются CODASYL-системами, или DBTG-системами. CODASYL-системы и системы на основе иерархических подходов пред­ставляют собой СУБД первого поколения.

Сетевая модель

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

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

Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия:

· каждый экземпляр типа P является предком только в одном экземпляре L;

· каждый экземпляр C является потомком не более, чем в одном экземпляре L.

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

A. Тип записи потомка в одном типе связи L 1 может быть типом записи предка в другом типе связи L 2 (как в иерархии).

B. Данный тип записи P может быть типом записи предка в любом числе типов связи.

C. Данный тип записи P может быть типом записи потомка в любом числе типов связи.

D. Может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L 1 и L 2 - два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться.

E. Типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком - в другой.

F. Предок и потомок могут быть одного типа записи.

Простой пример сетевой схемы БД приведен на слайде №5.2.

 

Рис.5.2. Пример схемы сетевой БД

Примерный набор операций при использовании сетевой модели может быть следующим.

· Найти конкретную запись в наборе однотипных записей (инженера Сидорова).

· Перейти от предка к первому потомку по некоторой связи (к первому сотруднику отдела 310).

· Перейти к следующему потомку в некоторой связи (от Сидорова к Иванову).

· Перейти от потомка к предку по некоторой связи (найти отдел Сидорова).

· Создать новую запись.

· Уничтожить запись.

· Модифицировать запись.

· Включить в связь.

· Исключить из связи.

· Переставить в другую связь и т.д.

 

3. Реляционная модель данных (»35 мин).

Однако иерархической и сетевой моделям присущи приведенные ниже недостатки.

• Даже для выполнения простых запросов с использованием переходов и досту­пом к определенным записям необходимо создавать достаточно сложные про­граммы.

• Независимость от данных существует лишь в минимальной степени.

• Отсутствие общепризнанных теоретических основ.

В 1970 году Э.Ф.Кодд (Е.F.Codd), работавший в исследовательской лаборатории корпорации IBM, опубликовал очень важную и весьма своевременную статью о реля­ционной модели данных, позволявшей устранить недостатки прежних моделей. Вслед за этим появилось множество экспериментальных реляционных СУБД, а пер­вые коммерческие продукты появились в конце 70-х - начале 80-х годов. Особенно следует отметить проект System R, разработанный в исследовательской лаборатории корпорации IBM, расположенной в городе Сан-Хосе, штат Калифорния, созданный в конце 70-х годов (Astrahan et al., 1976). Этот проект был задуман с целью доказать практичность реляционной модели, что достигалось посредством реализации преду­смотренных ею структур данных и требуемых функциональных возможностей. На основе этого проекта были получены важнейшие результаты.

• Был разработан структурированный язык запросов SQL, который с тех пор стал стандартным языком любых реляционных СУБД.

• В 80-х годах были созданы различные коммерческие реляционные СУБД — на­пример, DB2 или SQL/DS корпорации IBM или Oracle корпорации Oracle Corporation.

В настоящее время существует несколько сотен различных реляционных СУБД для мейнфреймов и микрокомпьютеров, хотя для многих из них определение реля­ционной модели носит несколько преувеличенный характер. В качестве примера многопользовательских СУБД может служить система CA-OpenIngres фирмы Computer Associates и систему Informix фирмы Informix Software, Inc. Примерами реляционных СУБД для персональных компьютеров являются Access и FoxPro фир­мы Microsoft, Paradox и Visual dBase фирмы Borland, а также R:Base фирмы Microrim. Реляционные СУБД относятся к СУБД второго поколения.

В конце 60-х годов появились работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, впервые был применен термин «реляционная модель данных».

Будучи математиком по образованию Э.Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.).

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

Доменом называется множество атомарных значений одного и того же типа. Так, на слайде №5.3...

Отношение на доменах D 1, D 2,..., Dn (не обязательно, чтобы все они были различны) состоит из заголовка и тела.

Заголовок состоит из такого фиксированного множества атрибутов A 1, A 2,..., An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i =1, 2,..., n).

Тело состоит из меняющегося во времени множества кортежей, где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (Ai: Vi), (i =1, 2,..., n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai: Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.

Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным,..., а степени n – n -арным.

Кардинальное число или мощность отношения – это число его кортежей. Кардинальное число отношения изменяется во времени в отличие от его степени.

Изменение кардинального числа отношения связано с изменением состояния отношения.

Рис.5.3. Отношение с математической точки зрения

(Ai - атрибуты, Vi - значения атрибутов)

 

Поскольку отношение – это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами A 1, A 2,..., An. Говорят, что множество атрибутов K =(Ai, Aj,..., Ak) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия.

1. Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj,..., Ak.

2. Минимальность: ни один из атрибутов Ai, Aj,..., Ak не может быть исключен из K без нарушения уникальности.

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

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

Отношение – Таблица (иногда Файл),

Кортеж – Строка (иногда Запись),

Атрибут – Столбец, Поле.

При этом принимается, что «запись» означает «экземпляр записи», а «поле» означает «имя и тип поля».

Отношение рассматривается как подмножество декартова произведения доменов.

Декартовым произведение доменов D1, D2, …, Dk

D = D1 ´ D2 ´ …´ Dk,

где D 1={ d 1.1, d 1.2, …, d 1. i ₁, …, d 1. n ₁}, D 2={ d 2.1, d 2.2, …, d 2. i ₂, …, d 2. n ₂}, …, Dk ={ dk. 1, dk. 2, …, dk.i_k, …, dk.n_k }, называется множество всех кортежей длины k, т.е. состоящих из k элементов – по одному из каждого домена Di.

Пример 5.1. Если D 1={ А, 2}, D 2={ B, C }, D 3={4, 5, D }, то k =3 и соответственно декартово произведение:

D = D 1´ D 2´ D 3={(A, B, 4), (A, B, 5), (A, B, D), (A, C, 4), (A, C, 5), (A, C, D), (2, B, 4), (2, B, 5), (2, B, D), (2, C, 4), (2, C, 5), (2, C, D)}.

Декартово произведение позволяет получить все возможные комбинации элементов исходных множеств – элементов рассматриваемых доменов.

Отношением R на множествах D 1, D 2, …, Dk называется подмножество декартова произведения D = D 1´ D 2´ …´ Dk. Отношение R, определенное на множествах D 1, D 2, …, Dk (причем не обязательно, чтобы эти множества были различными), есть некоторое множество кортежей арности k: (d 1. i ₁, d 2. i ₂, …, di.ik), таких, что d 1. i ₁ принадлежит D 1, d 2. i ₂ – D 2 и т.д.:

R Í D 1´ D 2´ …´ D k.

Элементами отношения являются кортежи. Арность кортежа определяет арность отношения. Поскольку отношение есть множество, то в нем не должны встречаться одинаковые кортежи и порядок кортежей в отношении несуществен.

Отношение может использоваться двояко:

1) для представления набора объектов;

2) для представления связей между наборами объектов.

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

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

Список имен атрибутов отношения называется схемой отношения. Если отношение называется R и его схема имеет атрибуты с именами А 1, А 2, …, Аk, то схема отношения

R (A 1, A 2, …, Ak).

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

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

 

3. Сравнительный анализ даталогических моделей (»10 мин).