Реферат: Базы данных

БАЗЫ ДАННЫХ
БАЗЫ ДАННЫХ 1

Вопрос №1. Архитектура банка данных 1

Вопрос №2. Классификация СУБД 2

Вопрос № 3 Этапы проектирования информационного обеспечения с использованием СУБД 4

Вопрос №4. Основные операции реляционной алгебры 7

Вопрос №5. Связь SQL с реляционной алгеброй 10

Вопрос №6. Основные операторы SQL 11

Вопрос №7. Концептуальная модель базы данных 13

Вопрос № 8 Критерии выбора СУБД 14

Вопрос № 9 Методы физической организации баз данных 16

Вопрос №10 Основы теории нормализации 23

Вопрос № 11 Методика построения объектно-реляционных моделей баз данных 28

Вопрос № 12 СУБД для ПЭВМ 31

Вопрос №13 Модели баз данных 33

Вопрос №14. Уровни отображения данных в СУБД 37

Вопрос № 15 Языки общения с СУБД (SQL, QBE) 41

Вопрос № 16. Отличие баз данных от файловых систем 45
^ Вопрос №1. Архитектура банка данных
В основе решения многих задач лежит обработка информации. Для облегчения обработки информации создаются информационные системы (ИС). Автоматизированными называют ИС, в которых применяют технические средства, в частности ЭВМ. Большинство существующих ИС являются автоматизированными, поэтому для краткости просто будем называть их ИС.

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

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

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

^ Система управления базами данных (СУБД) - это комплекс языковых и программных средств, предназначенный для создания, ведения и совместного использования БД многими пользователями. Обычно СУБД различают по используемой модели данных. Так, СУБД, основанные на использовании реляционной модели данных, называют реляционными СУБД.

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

Функционально СД присутствует во всех БнД, но не всегда выполняющий эти функции компонент имеет именно такое название. Чаще всего функции СД выполняются СУБД и вызываются из основного меню системы или реализуются с помощью ее утилит.

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

^ Вычислительная система (ВС) представляет собой совокупность взаимосвязанных и согласованно действующих ЭВМ или процессоров и других устройств, обеспечивающих автоматизацию процессов приема, обработки и выдачи информации потребителям. Поскольку основными функциями БнД являются хранение и обработка данных, то используемая ВС, наряду с приемлемой мощностью центральных процессоров (ЦП) должна иметь достаточный объем оперативной и внешней памяти прямого доступа.

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

^ Архитектура информационной системы

Эффективность функционирования информационной системы (ИС) во многом зависит от ее архитектуры. В настоящее время перспективной является архитектура клиент-сервер. В достаточно распространенном варианте она предполагает наличие компьютерной сети и распределенной базы данных, включающей корпоративную базу данных (КБД) и персональные базы данных (ПБД). КБД размещается на компьютере-сервере, ПБД размещаются на компьютерах сотрудников подразделений, являющихся клиентами корпоративной БД.

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

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

Исторически первыми появились распределенные ИС с применением файл-сервера. В таких ИС по запросам пользователей файлы базы данных передаются на персональные компьютеры (ПК), где и производится их обработка. Недостатком такого варианта архитектуры является высокая интенсивность передачи обрабатываемых данных. Причем, зачастую передаются избыточные данные: вне зависимости от того, сколько записей из базы данных требуется пользователю, файлы базы данных передаются целиком.

При архитектуре клиент-сервер сервер базы данных обеспечивает выполнение основного объема обработки данных. Формируемые пользователем или приложением запросы поступают к серверу БД в виде инструкций языка SQL. Сервер базы данных выполняет поиск и извлечение нужных данных, которые затем передаются на компьютер пользователя. Достоинством такого подхода в сравнении предыдущим является заметно меньший объем передаваемых данных.

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

компьютер-сервер, содержащий корпоративную и персональные базы;

компьютер-сервер и персональные компьютеры с ПБД;

несколько компьютеров-серверов и персональных компьютеров с ПБД.

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

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

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

Такая независимость достигается поддерживаемым СУБД многоуровневым представлением данных в БД на логическом (пользовательском) и физическом уровнях. Благодаря СУБД и наличию логического уровня представления данных обеспечивается отделение концептуальной (понятийной) модели БД от ее физического представления в памяти ЭВМ.
^ Вопрос №2. Классификация СУБД
В основу любой классификации закладывается признак классификации.

СУБД можно классифицировать по ряду признаков:

1. По модели данных

2. По типу используемого транслятора

3. По способности настраиваться на предметную область

4. По сфере применения

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

1. По модели данных

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

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

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

^ 2. По типу используемого транслятора

Важной характеристикой любой СУБД является используемый в ней тип транслятора (интерпретатор или компилятор). Программы написанные для системы-интерпретатора, используются лишь в присутствии самой системы. В настоящее время скорость работы таких программ не уступает скорости работы программ, сгенерированных компилятором. Есть много пакетов, которые имеют только один этот компонент. Собственно, СУБД - это, конечно, оболочка пользователя. В виду того, что такая среда ориентирована на немедленное удовлетворение его запросов, это всегда система-интерпретатор. Наличие в СУБД языка программирования позволяет создавать сложные системы обработки данных, ориентированные под конкретные задачи и даже под конкретного пользователя. Компилятор используется для придания завершенной программе вида готового коммерческого продукта в форме независимого EXE-файла.

^ 3. По способности настраиваться на предметную область

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

^ 4. По сфере применения

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

^ 5. По количеству одновременно открытых файлов и наличию языка программирования

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

^ Вопрос № 3 Этапы проектирования информационного обеспечения с использованием СУБД
Как и любой программный продукт, база данных обладает собственным жизненным циклом (ЖЦБД). Главной составляющей в жизненном цикле БД является создание единой базы данных и программ, необходимых для ее работы. Жизненный цикл системы базы данных определяет и жизненный цикл всей информационной системы организации, поскольку база данных является фундаментальным компонентом информационной системы.

ЖЦБД включает в себя следующие основные этапы:

планирование разработки базы данных;

определение требований к системе;

сбор и анализ требований пользователей;

проектирование базы данных:

концептуальное проектирование базы данных;

логическое проектирование базы данных;

физическое проектирование базы данных;

разработка приложений:

проектирование транзакций;

проектирование пользовательского интерфейса;

реализация;

загрузка данных;

тестирование;

эксплуатация и сопровождение:

анализ функционирования и поддержка исходного варианта БД;

адаптация, модернизация и поддержка переработанных вариантов.

Здесь представлен перечень основных этапов ЖЦБД. Ниже мы рассмотрим только те этапы, которые непосредственно относятся к теме проектирования.


^ Планирование разработки базы данных


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

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

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

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

Вторая часть — проверка операционной осуществимости — выяснение на­личия экспертов и персонала, необходимых для работы БД.

Третья часть — проверка экономической целесообразности осуществления проекта. При исследовании этой проблемы весьма важно дать оценку ряду факторов, в том числе и таким:

целесообразность совместного использования данных разными отделами;

величина риска, связанного с реализацией системы базы данных;

ожидаемая выгода от внедрения подлежащих созданию приложений;

время окупаемости внедренной БД;

влияние системы управления БД на реализацию долговременных планов организации.

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

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

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


^ Определение требований к системе


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

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

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


^ Сбор и анализ требований пользователей


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

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

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

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

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

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

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


^ Проектирование базы данных


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

Основными целями проектирования базы данных являются:

представление данных и связей между ними, необходимых для всех ос­новных областей применения данного приложения и любых существую­щих групп его пользователей;

создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных;

разработка предварительного варианта проекта, структура которого позволяет удовлетворить требования, предъявляемые к производительности системы.

В создании БД как модели ПрО выделяют:

объектную (предметную) систему, представляющую фрагмент реального мира;

информационную систему, описывающую некоторую объектную систему;

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

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

^ Концептуальное проектирование базы данных

Первая фаза процесса проектирования базы данных заключается в создании для анализируемой части предприятия концептуальной модели данных. По­строение ее осуществляется в определенном порядке: в начале создаются подробные модели пользовательских представлений данных; затем они интегрируются в концептуальную модель данных. Концептуальное проектирование приводит к созданию концептуальной схемы базы данных.

Существует два основных подхода к проектированию систем баз данных: "нисходящий" и "восходящий".

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

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

Нисходящий подход демонстрируется в концепции модели "сущность — связь" (Entity-Relationship model — ER-модель) — самой популярной техно­логии высокоуровневого моделирования данных, предложенной П. Ченом.

Модель "сущность—связь" относится к семантическим моделям. ^ Семанти­ческое моделирование данных, связанное со смысловым содержанием данных, независимо от их представления в ЭВМ, изначально возникло с целью по­вышения эффективности и точности проектирования баз данных. Методы семантического моделирования оказались применимы ко многим пользова­тельским проблемам и легко преобразуемы в сетевые, иерархические и реляционные модели.

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

В построении общей концептуальной модели данных выделяют ряд этапов.

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

Формулирование объектов, описывающих локальную предметную об­ласть проектируемой БД, и описание атрибутов, составляющих структуру каждого объекта.

Выделение ключевых атрибутов.

Спецификация связей между объектами. Удаление избыточных связей.

Анализ и добавление не ключевых атрибутов.

Объединение локальных представлений.

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

^ Логическое проектирование базы данных

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

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

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

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

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

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

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

На этом шаге желательно создание следующих документов:

набора подсхем;

спецификаций для физического проектирования приложений;

руководства по разработке программ (интерфейсы с пользователем и межпрограммные интерфейсы);

руководства по сопровождению БД.

Концептуальное и логическое проектирование — это итеративные процес­сы, которые включают в себя ряд уточнений, продолжающиеся до тех пор, пока не будет подучен наиболее соответствующий структуре предприятия продукт.

^ Физическое проектирование базы данных

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

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

создание описания набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;

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

разработка средств защиты создаваемой системы.




^ Разработка приложений


Параллельно с проектированием системы базы данных выполняется разра­ботка приложений. Главные составляющие данного процесса — это проек­тирование транзакций и пользовательского интерфейса.

^ Проектирование транзакций

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

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

Проектирование транзакций заключается в определении:

данных, которые используются транзакцией;

функциональных характеристик транзакции;

выходных данных, формируемых транзакцией;

степени важности и интенсивности использования транзакции.

Существует три основных типа транзакций: извлечения, обновления и сме­шанные транзакции.

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

Транзакции обновления используются для вставки новых, удаления старых или коррекции существующих записей базы данных.

^ Смешанные транзакции включают как операции извлечения, так и операции обновления данных.

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

^ Проектирование пользовательского интерфейса

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

Специалисты рекомендуют при проектировании пользовательского интерфейса использовать следующие основные элементы и их характеристики:

содержательное название;

ясные и понятные инструкции;

логически обоснованные группировки и последовательности полей;

визуально привлекательный вид окна формы или поля отчета;

легко узнаваемые названия полей;

согласованную терминологию и сокращения;

согласованное использование цветов;

визуальное выделение пространства и границ полей ввода данных;

удобные средства перемещения курсора;

средства исправления отдельных ошибочных символов и целых полей;

средства вывода сообщений об ошибках при вводе недопустимых значе­ний;

особое выделение необязательных для ввода полей;

средства вывода пояснительных сообщений с описанием полей;

средства вывода сообщения об окончании заполнения формы.



^ Вопрос №4. Основные операции реляционной алгебры
В основе реляционной БД лежит понятие «отношение», «связь».

Отношением r называется подмножество декартова произведения. Поля отношения (таблицы) могут располагаться в произвольном порядке. Чтобы установить определенный порядок для какой-либо конкретной реализации, вводят понятие «схема» R - множество упорядоченных имен атрибутов R(A1 , ..., An ).

Тогда реляционной БД d со схемой данных R называется совокупность отношений {r1 , ..., rn }, где для любой схемы R = {S, K} существует отношение в d, являющееся отношением со схемой S, удовлетворяющее любому ключу.

^ Реляционная алгебра. Пусть C1(L) - множество всех замкнутых формул системы L.

Если формула φC1(L), то говорят, что модель М удовлетворяет φ (φ = M), если φ истинно на М.

Пусть γC1(L). Формула Ψ называется следствием γ (выводима из γ, если из Ψ = M следует γ = М для любой модели М.

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

Пусть по-прежнему U - универсум (множество атрибутов), D - множество доменов, dom - полная функция из U (dom: U D), R = {Ri , i = 1, p} - множество схем отношений, d = {ri , i = 1, p} - множество всех отношений ri (Ri ), = {≠, =, ≤, ≥, < , >} - множество бинарных отношений (условий над доменами из D), О - множество операторов (операций), использующих атрибуты из U и отношения из .

Реляционная алгебра над U, D, dom, R, d, Q называется семиместным кортежем B = {U, D, dom, R, d, , O}.

^ В реляционной алгебре выделяют следующие операции: проекция обозначается π или P (в разных источниках), селекция (σ или S), cоединение (J), объединение (U), разность (DF), деление, пересечение, декартово произведение (CP). Пусть имеется два отношения (A, B, C) и P (D, E, F). Объединения, пересечения и вычитания (разность) производятся над отношениями одинаковой арности.

1. Операция объединения U (R, P) - без повторений строк:



2. Разность (DF(R, P)) - из R удаляются строки, имеющиеся в P:



3. Пересечение RP - общие элементы множеств:



4. Декартово произведение (СР(R, P)):



5. Проекция πS(A) (R), где S(A) - список доменов результирующего отношения из числа доменов отношения R: выбираются и упорядочиваются столбцы и удаляется избыточность из строк:



6. Селекция (выбор) σF (R), где F(Ai , , «константа») - исходное отношение n-арности; Ai - атрибут отношения R; или m - логическое условие (< , >, =, < >, , , ┐ ):



7. Соединение JAmB (R, P) = Q = σAmB :



8. Если сравниваемые поля, имена которых лучше сделать одинаковыми, в результирующем отношении «считаются» только один раз, то говорят о естественном соединении (слиянии) NJ:



где - список совпадающих атрибутов в исходном отношении; 1, ..., m - упорядоченный список всех компонентов декартова произведения , за исключением , ..., .



Если отношение состоит из одного кортежа, то при естественном соединении получается селекция.

9. Деление (X, Y)Y = X.

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

Пусть имеется



Наиболее часто используются операции селекции (S), проекции (P) и соединения (J), называемые SPJ-о