Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Ответы на ГОС экзамены - файл 1.doc


Ответы на ГОС экзамены
скачать (189 kb.)

Доступные файлы (1):

1.doc189kb.13.12.2011 05:42скачать

содержание

1.doc

Базы данных


  1. Реляционная модель данных. Ключи и индексы. Типы связей в реляционной базе данных.

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

  • Структурной части

  • Целостной части

  • Манипуляционной части


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

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

Вхождение домена в отношение принято называть атрибутом. Строки отношения называются кортежами.

Количество атрибутов в отношении называется степенью, или рангом, отношения.

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

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

Индекс (англ. index) — объект базы данных, создаваемый с целью повышения производительности выполнения запросов. Таблицы в базе данных могут иметь большое количество строк, которые хранятся в произвольном порядке, и их поиск по заданному значению путем последовательного просмотра таблицы строка за строкой может занимать много времени. Индекс формируется из значений одного или нескольких столбцов таблицы и указателей на соответствующие строки таблицы и, таким образом, позволяет находить нужную строку по заданному значению. Ускорение работы с использованием индексов достигается в первую очередь за счёт того, что индекс имеет структуру, оптимизированную под поиск - например, сбалансированного дерева.

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип – связь ^ ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В: Студент может не "заработать" стипендию, получить обычную или одну из повышенных стипендий.

Второй тип – связь ^ ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В: Квартира может пустовать, в ней может жить один или несколько жильцов.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи ^ МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

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

Существуют и более сложные связи:

  • множество связей между одними и теми же сущностями:

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

  • тренарные связи

врач может назначить несколько пациентов на несколько анализов, анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими врачами;

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




  1. ^ Нормализация данных.


Нормализация — это способ реализации связей и хранения данных в таблицах базы данных. Целью нормализации является устранение недостатков структуры базы данных, приводящих к вредной избыточности в данных, которая в свою очередь потенциально приводит к различным аномалиям и нарушениям целостности данных.
Теоретики реляционных баз данных в процессе развития теории выявили и описали типичные примеры избыточности и способы их устранения.

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


Номер_заказа

Номера_товаров

Сумма

1

2346, 3456, 2345

23456 р.

2

3456, 5032

4578 р.

3

4509

123р.

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


Номер_заказа

Номера_товаров

Сумма

1

2346

100

1

3456

200

1

2345

346

2

3456

234

2

5032

123

3

4509

100


Рис. 2. В таблице, приведенной к первой нормальной форме (1NF), каждая строка является одинарной, или атомарной, записью. Все эти элементы должны сохраняться отдельно.
Пока вам достаточно знать, что в 1NF на пересечении строки и столбца должна находится только одна единица информации.
^ Вторая нормальная форма
Первым условием для второй нормальной формы — 2NF — является выполнение требований предъявляемых к 1NF. Второе условие состоит в том, что у каждой строки таблицы базы данные должен быть уникальный идентификатор. Для этого в большинстве случаев вы должны добавить каждой строке этот уникальный идентификатор. При рассмотрении предыдущего примера, показанного на рис. 2, вам могло показаться, что таблица удовлетворяет второму правилу. Ведь у нас есть идентификатор или номер заказа, который в сочетании с кодом элемента даст уникальный идентификатор строки, не правда ли? Нет, неправда.

У вас вполне может быть единственный заказ, содержащий несколько экземпляров некоторого товара. Представьте себе, что вы идете в магазин и покупаете молоко на всю неделю. Если вы большой любитель молока, то почти наверняка возьмете несколько литровых пакетов. Таким образом, мы получим несколько одинаковых элементов в одном и то же заказе.
Поэтому, чтобы выполнить второе требование модели 2NF, нужно добавить к таблице столбец OrderItemID (рис. 3). Таким образом, у вас будет и столбец OrderNum, и OrderItemID. В последнем будут содержаться уникальные идентификаторы строк.


Уникальный

идентификатор

Номер_заказа

Номер_товара

Наименование

1

1

23345

Хлеб чёрный

2

1

678

Сахар

11

1

789

Чай

4

2

23456

Молоко

5

2

8945

Батон

6

3

7890

Шоколад


Рис. 3. Теперь, когда у каждой строки есть уникальный идентификатор, таблица удовлетворяет второму требованию модели 2NF

Обратите внимание на элемент, который был добавлен под номером 11. Он находится не в низу столбца, а в середине. Все дело в том, что порядок расположения элементов в столбцах определяется номером заказа. А так как одиннадцатый элемент относится к заказу 1, то его добавили в конце списка элементов заказа 1.
^ Третья нормальная форма
Третья нормальная форма, или 3NF, —это настоящее спасение для разработчика. Так же, как и в случае с моделью 2NF, когда первым условием была согласованность с моделью 1NF, модель 3NF требует согласования моделью 2NF, т.е. выполнения всех ее условий. Коротко это можно выразить так: в таблице модели 3NF не должно быть избыточных неключевых столбцов, связанных с неключевыми столбцами других таблиц.

Главная цель нормализации таблицы — избавиться от избыточной информации, содержащейся в неключевых столбцах. При первом взгляде на рис. 4 кажется, что модель построена правильно. Но есть одна проблема. Все описания сохраняются в таблице и, вероятно, используются где-то еще в базе данных. Но сохранять их в таблице по отдельности довольно сложно.
Вот тут-то и становятся очевидными преимущества перехода к модели 3NF. Вспомните простой пример с покупкой молока в магазине, который приведен выше. Представьте себе следующую ситуацию. Предположим, вы сохранили информацию в таком виде, как показано на рис. 3. Затем вам понадобилось изменить описание Молоко на Молоко 2%, так как вашего поставщика черт дернул добавить к ассортименту описание Молоко 1%. Вам нужно написать утилиту для обновления таблиц базы данных с информацией о продажах, а также всех остальных таблиц, где есть ссылка на описание Молоко, чтобы вставить нужное процентное соотношение. Несогласованность информации в базе данных — это настоящий кошмар, который почти всегда приводит к возникновению ошибок. Если вы забудете хотя бы об одной таблице, которую нужно обновить, то все данные о продажах молока будут бесполезными.
Путь к решению проблемы — нормализация. Как показано на рис. 4, мы решили эту проблему очень просто — вообще удалили столбец описаний из таблицы. Поскольку описанию Молоко уже присвоен код товара, у вас есть информация, которую нужно внести в таблицу Ассортимент, показанную

на рис. 5.

Уникальный

идентификатор

Номер_заказа

Номер_товара

1

1

23345

2

1

678

11

1

789

4

2

23456

5

2

8945

6

3

7890

Рис. 4. Чтобы подчинить таблицу условиям модели 3NF, мы удалили из нее столбец описаний.


Номер_товара

Описание

Цена

23456

Хлеб

1

4546

Молоко

1.2

2445

Кефир

1.5

6789

Сметана

2

Рис. 5. Создав таблицу Ассортимент, вы можете ссылаться на ее элементы
Конечно, занявшись нормализацией таблицы, вы можете вдруг задаться вопросом: как получить полную информацию о проданном элементе? Как узнать его описание, цену и т.д.? Вот тут-то вам и пригодятся реляционные базы данных и их режимы. В данном примере вы можете создать запрос, который быстро соберет для вас всю необходимую информацию. На рис. 4.6 показано, какую информацию возвратит запрос приложению.


Номер_заказа

Номер_товара

Описание

Цена

1

3456

Хлеб

1

1

75456

Молоко

1.2

2

45656

Кефир

1.5

2

5656

Сметана

2

Рис. 6. Если задать реляционные отношения между таблицами базы данных, то можно выполнить любую выборку информации, даже если она разбросана по нескольким таблицам.
Комбинируя информацию из двух таблиц, вы будете по-прежнему получать полные наборы данных, но при этом источники информации будут ограничены. Вы поймете, что способ представления информации не меняется; меняется только способ ее выборки. Это наглядный пример модели 3NF, т.е. когда информацию можно выбрать различными способами, которые в данном случае являются логическими отображениями двух связанных таблиц.


  1. Типы баз данных.


Типы СУБД:

  • Иерархическая

  • Сетевая

  • Реляционная

  • Обьектно-ориентированная

  • Гибридные


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

Если структура запроса совпадает со структурой иерархической БД, то такая модель данных обладает самым высоким быстродействием и потому чаще всего применяется в суперЭВМ. В противном случае быстродействие может резко снизиться или данные совсем могут быть не получены. Чтобы избежать последнего неприятного случая, в иерархическую МД вводят еще один тип связи – логическую.

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

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

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

1) все типы связей функциональные (1:1, 1:М, М:1);

2) структура связей древовидная.

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

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

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

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


  1. Основные этапы проектирования баз данных.


1. Концептуальное проектирование — сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:

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

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

моделирование и интеграция всех представлений
По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели «сущность-связь».
2. ^ Логическое проектирование — преобразование требований к данным в структуры данных. На выходе получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.
3. ^ Физическое проектирование - определение особенностей хранения данных, методов доступа и т. д.
Различие уровней представления данных на каждом этапе проектирования реляционной базы данных:
КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ — Представление аналитика (используется инфологическая модель «сущность-связь»)

* сущности

* атрибуты

* связи
ЛОГИЧЕСКИЙ УРОВЕНЬ — Представление программиста

* записи

* элементы данных

* связи между записями
ФИЗИЧЕСКИЙ УРОВЕНЬ — Представление администратора

* группирование данных

* индексы

* методы доступа


  1. ^ Запросы к базам данных. Компоненты языка SQL и их назначение.

SQL – это структурированный язык запросов (Structured Query Languge). Он был разработан в 70-е годы в корпорации IBM в качестве стандартизированного метода для выборки данных из Баз Данных различных форматов. Целью было получение языка, который бы не базировался ни на одном из существующих языков программирования и в тоже время мог бы быть использован в любом языке программирования для выборки и обновления информации в Базах Данных.

Синтаксис языка SQL установлен комитетом Американского национального института стандартов (ANSI). Наиболее популярным стандартом SQL является SQL-89, опубликованный в 1989 году, уточненная версия стандартов была разработана тремя годами позже – SQL-92.

Команды SQL делятся на две категории:

  • Команды языка определения данных (Data Definition Language - DDL), которые позволяют использовать запросы SQL для создания таких компонентов Баз Данных, как таблицы, поля и индексы;

  • Команды языка манипулирования данными (Data Manipulation Languge - DML) разработанные для выборки записей из Базы Данных;

SQL – оператор состоит из трех частей:

  • Объявления параметров. Необязательные параметры, которые передаются в SQL-оператор программой. (Используются редко.);

  • Управляюший оператор. Часть оператора, которая сообщает ядру обработки запросов тип операции;

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

Управляющие операторы бывают следующих видов:

DELETE FROM – удаляет записи из таблицы;

INSERT INTO - добавляет группу записей в таблицу;

SELECT – возвращает группу записей, размещая их в динамическом наборе или таблице;

UDATE – устанавливает значения полей в таблице;

К опциональным объявлениям относятся разного рода директивы типа WHERE, GROUP BY, ORDER BY.

  1. Операторы SQL.

SQL содержит 4 группы операторов:

  • Операторы описания данных: CREATE, DROP, ALTER и др.

  • Операторы манипуляции данными: INSERT, DELETE, SELECT, UPDATE и др.

  • Операторы задания прав доступа в базе данных: GRANT / REVOKE , LOCK / UNLOCK , SET LOCK MODE

  • Операторы защиты, восстановления данных и прочие операторы.

1. Операторы Описания Данных.

Операторы описания данных предназначены для описания (создания), изменения описания и уничтожения объектов базы данных.

В SQL различаются следующие виды объектов:

  • база данных (database);

  • таблица (table);

  • столбец (column);

  • индекс (index);

  • снимок (view);

  • синоним (synonym).

Каждый объект имеет собственное имя - идентификатор. Каждый объект имеет владельца - т.е. того пользователя, который его создал. Имя объекта можно уточнять с помощью имени его владельца (owner-name) в такой форме: moshkow.table1

^ 2. Операторы задания прав доступа в базе данных.

Выдавать и забирать права доступа к таблице может владелец таблицы, Администратор Базы Данных (имеющий DBA права), а так же пользователь, которому было выдано право выдавать права (Оператором GRANT WITH GRANT OPTIONS).

Отобрать у вас права DBA (если вы, конечно, им являетесь) может только другой DBA. На время транзакции все измененные строки автоматически блокируются системой от изменения (но не от просмотра). Вы можете явно блокировать всю таблицу целиком, тогда система не будет блокировать строки по отдельности. Вы можете блокировать таблицу целиком не только от изменения но и от просмотра. Если ваш оператор пытается записать в блокированную другим пользователем строку, то оператор "сваливается". Вы можете установить для своей программы режим "Ждать разблокирования строк":

SET LOCK MODE TO WAIT

^ 3. Операторы транзакций и восстановления данных.

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

Поскольку за все хорошее приходится платить, наличие системного журнала у базы данных вызывает заметный рост накладных расходов и замедление работы запросов. К тому же при активной работе с базой системный журнал быстро "распухает". За ним нужно следить и периодически чистить. Если во время транзакции программа "свалилась" то INFORMIX автоматически сделает откатку.

^ 4. Операторы Манипуляции Данными.

Следующая группа операторов предназначена для манипулирования данными в таблицах. В нее входят операторы выбора (SELECT) строк из таблицы (или таблиц), уничтожения (DELETE) строк в таблице, вставки (INSERT) строк, и изменения (UPDATE) значений в существующих в таблице строках.

^ Оператор DELETE.

Уничтожить в таблице kadry все строки, в которых номер цеха равен 4, а фамилия кончается на буквы "ов"

DELETE FROM kadry WHERE ceh=4 AND fio MATCHES "*ов"

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

А этот оператор уничтожит ВСЕ строки в таблице kadry, владельцем которой является moshkow, но не саму таблицу

DELETE FROM moshkow.kadry

^ Простейшая форма оператора SELECT.

Первый пример находит в таблице kadry строку, в которой столбец tabnum=345 . Из этой строки берутся только три указаных столбца. Второй пример выбирает ВСЕ строки из таблицы ceh, и все столбцы.

SELECT fio, dolvn, zarplata FROM kadry WHERE tabnom=345

SELECT * FROM ceh

SELECT kadry.fio, ceh.nameceh WHERE kadry.nomerceh=ceh.nomerceh

Третий пример выбирает фамилии работников из таблицы кадры, а названия цехов, в которых они работают, из таблицы ceh.

^ Оператор INSERT.

Может вставить в таблицу одну строку, если используется в форме INSERT INTO ... VALUES, а может вставить в таблицу целый набор строк, выбранных подзапросом SELECT из другой таблицы.

INSERT INTO kadry VALUES (4,0,"Грицько",num,"10/25/1939",NULL)

INSERT INTO customer VALUES (ps_customer.*)

# ps_customer - переменная типа RECORD - аналог структуры в

# языке Си. Этот оператор вставляет значения элементов записи

# ps_customer в соответствующие поля таблицы customer

INSERT INTO kadry (tabnom, fio, nomerceh, dolvnostx)

SELECT 0 , fio, 4, dolvnostx FROM kadryold

WHERE nomerceh=3 AND fio IS NOT NULL

# последний оператор вставляет сразу несколько строк

Если мы хотим, чтобы при вставлении строки в столбец типа SERIAL автоматически заносилось очередное значение счетчика, нужно вставлять в этот столбец константу 0. Если не во все столбцы вставляемой строки вносится значение (как это сделано в третьем операторе), то незаполненные столбцы заполняются значением NULL.

В операторах DELETE, UPDATE, SELECT может присутствовать WHERE предложение, в котором можно задать условия на строки, которые требуется обработать (соответственно уничтожить, изменить или выбрать).

^ Оператор UPDATE.

Меняет значения столбцов, в строках, удовлетворяющим WHERE условию.

UPDATE kadry SET fio="Зыкова" WHERE fio="Гирусова"

UPDATE ceh SET kod_ceha[1,4]=nameceh[5,8] WHERE

nomerceh BETWEEN 3 AND 5 OR nameceh IN ("токарный","литейный")

В таблице ceh в цехах номер 3,4,5 а так же в токарном и литейном первые четыре символа в коде цеха будут заменены на подстроку поля nameceh из той же строки.

  1. ^ Понятие целостности данных. Примеры практической реализации.

Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7).

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

Современные СУБД имеют ряд средств для обеспечения поддержания целостности (так же, как и средств обеспечения поддержания безопасности).

Выделяют три группы правил целостности:

1. Целостность по сущностям.

2. Целостность по ссылкам.

3. Целостность, определяемая пользователем.

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

  • категорийная целостность;

  • ссылочная целостностью

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

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

  1. ^ Транзакции и проблемы многопользовательского режима работы.

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

Методом контроля за транзакциями является ведение журнала, в котором фиксируются все изменения, совершаемые транзакцией в БД. Если во время обработки транзакции происходит сбой, транзакция откатывается - из журнала восстанавливается состояние БД на момент начала транзакции.

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

  • COMMIT - успешно завершить транзакцию

  • ROLLBACK - откатить транзакцию, т.е. вернуть БД в состояние, в котором она находилась на момент начала транзакции.

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

  • оператор COMMIT означает успешное завершение транзакции, все изменения, внесненные в базу данных делаются постоянными

  • оператор ROLLBACK прерывает транзакцию и отменяет все внесенные ею изменения

  • успешное заверешение программы, инициировавшей транзакцию, означает успешное завершение транзакции (как использование COMMIT)

  • ошибочное завершение программы прерывает транзакцию (как ROLLBACK)

^ Конфликты доступа

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

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

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

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

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

  1. ^ Особенности проектирования реляционной модели данных на платформе клиент-сервер.



  1. Технологии ODBC, OLE DB, ADO и ADO.NET

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

Программные средства поддержки ODBC корпорация Microsoft обычно поставляет вместе с СУБД. На сегодня ODBC является стандартом, используемым целым рядом продуктов, в частности, PowerBuilder, FoxPro, Visual C++, Visual Basic, Delphi, Microsoft Access и многими другими.

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

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

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

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

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

^ Технология OLE DB.

Технология OLE DB построена на ODBC и расширяет ее до компонентной архитектуры, которая обеспечивает высокоуровневый интерфейс доступа к данным. Эта архитектура предоставляет постоянный доступ к SQL-данным, не SQL-данным и неструктурированным источникам данных по локальным сетям и Internet. В действительности для доступа к SQL-данным OLE DB использует ODBC, потому что это самая подходящая архитектура для работы с SQL.

На Рисунке 5 показано, что OLE DB состоит из трех компонентов: потребителя данных (например, приложения); поставщика (провайдера) данных, который содержит и предоставляет данные; служебного компонента, который обрабатывает и транспортирует данные (в частности, процессоры запросов, процессоры курсоров).



Рисунок 5.

ADO.

OLE DB обеспечивает связывание для программистов на С и C++, а также программистов, использующих языки с С-подобными вызовами функций. Такие языки, как VB и VBScript, не поддерживают тип данных «указатель» (адресных переменных). Следовательно, они не могут использовать связывание в стиле С и прямое обращение к OLE DB.

Вероятно, для большей путаницы разработчики Microsoft ввели еще одну объектную модель доступа к данным: ADO. ADO работает с объектами DAO и RDO, а также поддерживает более простые модели, чем DAO и RDO (хотя с избыточной функциональностью, так что можно выполнить операцию несколькими способами). Объектная иерархия в ADO более однородная, чем в DAO. ADO содержит несколько встроенных объектов, которые упрощают доступ к данным из информационных хранилищ.

На Рисунке 6 показано несколько способов, с помощью которых приложение связывается с базой данных. Например, VB-программист может использовать ADO для соединения приложения с провайдером OLE DB. Если база данных не поддерживает OLE DB, приложение может задействовать ODBC. Программист на Visual C++ может применять ADO или соединяться напрямую через OLE DB.



Рисунок 6. Различие маршрутов приложений в ADO.

ADO.NET

Когда Microsoft начала разрабатывать .NET Framework, она имела хорошую возможность пересмотреть модель доступа к данным. Решив не продолжать разработку технологии ADO, специалисты Microsoft приступили к созданию новой структуры доступа к данным, при этом сохранив акроним. Microsoft разрабатывает ADO.NET на базе уже зарекомендовавшей себя объектной технологии ADO. Но ADO.NET ориентируется на три важные возможности, которые не поддерживаются ADO: поддержка модели доступа к несвязанным данным, что является ключевым элементом для работы в Web; поддержка тесной интеграции с XML; интеграция с .NET Framework (например, совместимость с базовой библиотекой классов типичной системы).


Скачать файл (189 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации