Базы данных. (5-й семестр вмк)

Самитов Р.К.

Базовые типы данных.

¨ CHAR(k) и VARCHAR(k) – строковый тип, соответственно фиксированной длины k и переменной длины £ k (VARCHAR(k) ~ string[ k ] в Паскаль).

¨ INTEGER – целочисленный тип.

¨ NUMERIC(k,m) – вещественный тип в форме с фиксированной точкой (k,m – ширина и точность, как в форматах вывода Паскаль).

¨ DATE и TIMESTAMP – тип дата-время.

Ключи таблиц.

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

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

¨ Первичный ключ (PRIMARY KEY)– выделенный уникальный ключ таблицы. В качестве первичного может быть объявлен любой уникальный ключ, но только один.

Межтабличные связи и ключи. Межтабличную связь можно объявить только для пары таблиц (бинарную) и только типа (1:N) – (Родительская таблица: Дочерняя таблица).

Связь определяется с помощью пары ключей: родительский ключ (REFERENCES) – один из уникальных ключей родительской таблицы (чаще всего, это ее первичный ключ), внешний ключ (FOREIGN KEY) – ключ дочерней таблицы (как правило, это неуникальный ключ).

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

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

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

Связь объявляется при дочерней таблице

§ поэтому внешний ключ (FOREIGN KEY) содержит ее же поля;

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

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

Ограничения целостности можно классифицировать.

¨ Внутритабличные горизонтальные. Каждая строка таблицы (или конкретное поле каждой строки) должна удовлетворять объявленному условию: заданному обычным логическим выражением (CHECK) или специальными, например NOT NULL – поле должно иметь непустое значение (*).

¨ Внутритабличные вертикальные. Набор значений в конкретном списке колонок таблицы (конкретного списка полей по всем строкам) должен удовлетворять условию неповторяемости - UNIQUE, PRIMARY (влечет UNIQUE);

¨ Межтабличные (ограничения ссылочной целостности). Для каждой строки дочерней таблицы межтабличной связи, если значение ее внешнего ключа не NULL, то должна существовать строка в соответствующей родительской таблице с таким же значением родительского ключа.

Стратегии поддержания ссылочной целостности. Существуют две основные стратегии поддержания ссылочной целостности.

¨ RESTRICT (ОГРАНИЧИТЬ) - не разрешать выполнение операции, приводящей к нарушению ссылочной целостности. Это самая простая стратегия, требующая только проверки, для строки дочерней таблицы имеется ли соответствующая строка в родительской таблице.

¨ CASCADE (КАСКАДИРОВАТЬ) - разрешить выполнение требуемой операции, но внести при этом необходимые поправки в других таблицах так, чтобы не допустить нарушения ссылочной целостности и сохранить все имеющиеся связи. Изменение начинается в родительской таблице и каскадно выполняется в дочерней таблице. В реализации этой стратегии имеется одна тонкость, заключающаяся в том, что дочерняя таблица сама может быть родительской для некоторой третьей таблицы. При этом может дополнительно потребоваться выполнение какой-либо стратегии и для этой связи и т.д. Если при этом какая-либо из каскадных операций (любого уровня) не может быть выполнена, то необходимо отказаться от первоначальной операции и вернуть базу данных в исходное состояние. Это самая сложная стратегия, но она хороша тем, что при этом не нарушается связь между строками родительской и дочерней таблиц.

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

Средства описания баз данных (DDL) в SQL.

CREATE TABLE ИмяТаблицы

(Колонка,... [, ОграничениеТаблицы,...])

Колонка = ИмяКолонки ТипКолонки

[DEFAULT Константа ] [ ОграничениеКолонки... ]

ОграничениеКолонки =

NOT NULL | UNIQUE | PRIMARY KEY | CHECK(Условие)

| REFERENCES ИмяРодительскойТаблицы

[(ИмяЕеКолонки)] [ СтратегияПоддержки ]

ОграничениеТаблицы =

CHECK(Условие)

| UNIQUE (ИмяКолонки,...)

| PRIMARY KEY (ИмяКолонки,...)

| FOREIGN KEY (ИмяКолонки,...)

REFERENCES ИмяРодительскойТаблицы

[(ИмяЕеКолонки,...)] [ СтратегияПоддержки ]

СтратегияПоддержки =

ON DELETE CASCADE

| ON UPDATE CASCADE

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

§ Метасимволы: [] – «может отсутствовать», | - «один из вариантов», ... – «допустимо повторение через предыдущий символ».

§ ОграничениеКолонки UNIQUE | PRIMARY KEY | REFERENCES используются в случае несоставного ключа, а иначе эти ограничения описываются как ОграничениеТаблицы.

§ CHECK(Условие) используется как ОграничениеТаблицы, если Условие зависит более чем от одного поля.

§ Если в ограничении ссылочной целостности не указан родительский ключ, то по умолчанию родительским считается первичный ключ (PRIMARY KEY) родительской таблицы.

§ Если в ограничении ссылочной целостности не указана СтратегияПоддержки, то по умолчанию действует стратегия RESTRICT (ОГРАНИЧИТЬ).

ПРИМЕР.

/* Table: PSTS, ПОСТАВЩИКИ */

CREATE TABLE PSTS

(

KPST INTEGER DEFAULT 0 NOT NULL PRIMARY KEY,

IMPST VARCHAR(20) DEFAULT '',

ADRPST VARCHAR(30) DEFAULT ''

);

/* Table: DET, ДЕТАЛИ */

CREATE TABLE DET

(

KDET INTEGER DEFAULT 0 NOT NULL PRIMARY KEY,

IMDET VARCHAR(20) DEFAULT '',

CVET VARCHAR(10) DEFAULT ''

);

/* Table: DOG, ДОГОВОРА */

CREATE TABLE DOG

(

KPST INTEGER DEFAULT 0 NOT NULL REFERENCES PSTS,

KDET INTEGER DEFAULT 0 NOT NULL REFERENCES DET,

KOL INTEGER,

DTN DATE,

DTK DATE,

PRIMARY KEY (KPST, KDET), CHECK (DTN<DTK)

);

/* Table: PST, ПОСТАВКИ */

CREATE TABLE PST

(

KPST INTEGER DEFAULT 0 NOT NULL,

KDET INTEGER DEFAULT 0 NOT NULL,

KOL INTEGER,

DTP DATE CHECK (DTP>'01.01.2000'),

FOREIGN KEY (KPST, KDET) REFERENCES DOG

);

Выражения в SQL.

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

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

Групповые выражения строятся с помощью групповых функций.

§ SUM([DISTINCT] ПростоеВыражение) имеет значением сумму значений ПростогоВыражения по всем строкам группы.

Если указано уточнение DISTINCT, то каждое из полученных для строк группы значений ПростогоВыражения участвует в сумме точно один раз без повторений.

§ Аналогичный смысл у групповых функций AVG (среднеарифметическое), MAX (максимальное), MIN (минимальное).

§ COUNT(Аргумент), где

Аргумент = * | DISTINCT ПростоеВыражение

имеет значением для Аргумент = * - количество строк в группе, а для другого вида Аргумента –количество различных значений ПростогоВыражения по всем строкам группы.

ПРИМЕР. Пусть таблица поставок PST сгруппирована по ключу группировки PST.KDET.

COUNT(DISTINCT PST.KPST) – количество разных поставщиков уже поставивших деталь KDET.

COUNT(*) – количество партий этой детали уже полученных от всех поставщиков.

SUM(PST.KOL) – общее количество в штуках детали KDET уже полученное, суммарно по всем поставщикам.

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

· Условия. Выражения этого вида играют в SQL особую роль. Это логические выражения, которые используются как УсловияхОтбора (до и после группировки).

Ниже Выражение – простое или групповое выражение.

§ Выражение Сравнение Выражение

Набор операций Сравнения для базовых типов данных: = < > и т.п.

§ Выражение Сравнение SelectOne-оператор

SelectOne-оператор должен строить одно колоночную таблицу с одной строкой.

§ Выражение [NOT] BETWEEN Выражение AND Выражение

E1 BETWEEN E2 AND E3 в терминах языка Паскаль имеет смысл E1 IN [ E2.. E3 ], а NOT – отрицание.

§ Выражение [NOT] IN (Выражение,...)

E1 IN (E2,...) в терминах языка Паскаль: E1 IN [ E2,... ].

§ Выражение [NOT] IN (SelectList-оператор)

SelectList-оператор строит одно колоночную таблицу.

§ Выражение Сравнение {ALL|SOME} (SelectList-оператор)

E > ALL (SelectList-оператор) имеет смысл: E строго больше всех значений из строк одно колоночной таблицы. SOME... хотя бы одного значения...

§ EXISTS (Select-оператор)

Имеет смысл: результат Select-оператора непустая таблица.

Из вышеприведенных условий можно строить более сложные с помощью операций логики высказываний: AND OR NOT.

IF NOT aDet THEN BEGIN

{aDet:=eDog:= $dogÎDog Условие(r,det,dog)}

eDog:=false; DogTable.First;

DogTable.Next

END;

aDet:=eDog

END;

DetTable.Next

END;

IF aDet THEN BEGIN

NewTable.Append;

NewTable.FieldByName('ImPst').Value:=

PstsTable.FieldByName('ImPst').Value; NewTable.Post;

END;

PstsTable.Next;

END; NewTable.Close;

Поскольку (KPst,KDet) является первичным ключом для таблицы Dog (а значит имеется соответствующий индекс), то выделенный жирным курсивом фрагмент можно заменить на:

aDet:=(DetTable.FieldByName('Cvet').

AsString<>’Красная’) OR

DogTable.FindKey([PstsTable.FieldByName('KPst').Value,

DetTable.FieldByName('KDet').Value]);

Список литеpатуpы.

1. Гарсиа-Молина Г., Ульман Д., Уидом Д. Системы баз данных. М.:Вильямс,2003. - 1088 с.

2. К. Дейт. Введение в системы баз данных. М.: Вильямс, 2001.-1072 с.

3. М. Грабер М. SQL. Справочное руководство. М.: Лори, 1998. - 292 с.; 2001. - 354 с.

4. Ульман Д.Д. Введение в системы баз данных. М.: «Лори»,2000.-374 с.

5. Фаронов В. Программирование баз данных в Delphi 6. М.: Питер, 2003. - 352 с.

6. Т. Конноли, К. Берг, А. Страчан. Базы данных. М.: Вильямс, 2000. - 1120 с.

7. Дж.С. Боуман, С.Л. Эмерсон, М. Дановски. Практическое руководство по SQL. М.: Вильямс, 2001. - 336 с.

8. Черемных С.В. и др. Структурный анализ систем: IDEF-технологии. - М.: ФиС, 2001 - 208 с.

9. Черемных С.В. и др. Моделирование и анализ систем. IDEF-технологии: практикум. - М.: ФиС, 2002 - 192 с.

10.Маклаков С.В. Моделирование бизнес процессов. - М.: ДИАЛОГ-МИФИ, 2002. - 224 с.

Гл. pед. физ.-мат. лит., 1989. - 288 с.

25.Мейер Д. Теория реляционных баз данных. М.:Мир, 1987. - 608 с.

26.Вендеров А.М. CASE-технология. М.: Финансы и статистика, 1998. - 176 с.

27.Кравченко В.Ф. и др. Организационный инжиниринг. М.: Издательство ПРИОР, 1999. - 256 с.

28.А.Р. Саймон. Стратегические технологии баз данных. М.: ФиС, 1999. - 479 с.

29.Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1983. – 320 с.

30.Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989. – 351 с.

31.Кириллов В.В. Структуризованный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с.

32.Мартин Дж. Планирование развития автоматизированных систем. – М.: Финансы и статистика, 1984. – 196 с.

33.Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., – М.: Мир, 1985. Кн. 1. – 287 с.: Кн. 2. – 320 с.

34.Ульман Дж. Базы данных на Паскале. – М.: Машиностроение, 1990. – 386 с.

35.Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 1984. – 294 с.

ПРИМЕРЫ ВОПРОСОВ НА (ПИСЬМЕННОМ) ЭКЗАМЕНЕ ПО БД.

==========================================================

1. Дано выражение реляционной алгебры или запрос реляционного исчисления кортежей (типа рассмотренного в лекциях «о поставщиках, которые поставляют все красные детали»).

Ø сформулировать его содержание на русском языке, т.е. задачу, которую решает заданное выражение или запрос;

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

Варианты требований к программе: на SQL, на Object Pascal2 (Delphi).

2. Дана Паскаль-программа типа:

PROGRAM PP; VAR a,b,x,y,t,s:REAL;

BEGIN READ(a,b); IF sin(a)>b THENBEGIN x:=tg(a);y:=tg(b) ENDELSE

BEGIN x:=t; WHILE x>cos(x) DOBEGIN s:=sin(cos(x));x:=tg(s) END;

IF sin(x)>cos(x) THENBEGIN t:=x;y:=tg(t) ENDELSE y:=tg(x) END; WRITE(x,y) END....но более «громоздкая»...

Ø Нарисовать соответствующую потоковую диаграмму информационных связей (с хранилищами).

3. Дан фрагмент Паскаль-программы, который содержит описание структуры некоторого хранилища данных, например:

Файл содержит папку сведений о товарах на складах предприятия. Каждый компонент файла содержит сведения об одном виде товаров за один месяц:

· наименование товара, единица измерения;

· сведения о наличии и движении этого товара за этот месяц:

· год и месяц сведений;

· сведения на начало месяца о наличии этого товара на складах - для каждого из 15-ти складов: количество этого товара, имевшееся на начало месяца на этом складе, и его стоимость;

· сведения о движении этого товара на складах - для каждого из 15 складов:

· наименование склада и ФИО ответственного лица;

· движение этого товара на этом складе - для каждого из 31-го дней месяца для каждой из 10-ти возможных операций: вид операции (поступление или выбытие); количество и стоимость соответственно поступившего или выбывшего товара; наименование организации соответственно поставившей или получившей этот товар.

VAR TV: FILEOFRECORD naimt,edt:STRING; sved: RECORD god,mes:INTEGER;

svednal: ARRAY [1..15] OFRECORD kol,stoim:REAL END;

sveddv: ARRAY [1..15] OFRECORD naims,FIOs: STRING; dv: ARRAY [1..31]

OFARRAY [1..10] OF RECORD vidop:STRING; kold,stoimd:REAL;

naimorg: STRING ENDENDENDEND

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

Ø... возможно будет вариант: нормализовать и привести к одной таблице, описать функциональные зависимости, замыкание которых полно для этой БД... в приемлемом смысле...

(*) Сегодня интенсивно развиваются компонентные технологии в целом, и в частности технологии доступа к данным, обеспечивающие независимость прикладных приложений от источников данных (не только SQL- ориентированных, но и WEB- ориентированных и других…). ODBC и BDE естественно не единственно возможные средства обеспечения доступа к данными... есть стандарт CORBA (Common Object Request Broker Architecture), ADO (Microsoft ActiveX Data Objects)...

(*) Кстати, NULL- значение (пустое, неопределенное) не обязательно совпадает с 0 (или пробел). Обычно NULL- значение можно ввести, выделив и удалив (Del) текущее значение поля, но реально этот вопрос зависит от некоторых настроек.

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

(*) Фактически эти средства тесно связаны с понятием «транзакция».

Средства управления транзакциями класса TDatabase:

procedure StartTransaction {стартует транзакцию};

procedure Commit {завершает подтверждением};

procedure Rollback {завершает «откатом»};

BDE поддерживает явное управление только неименованными транзакциями, причем с ограниченным набором уровней изолированности (property TransIsolation). Однако, аккуратно используя объекты типа TQuery, TStoredProc, TUpdateSQL (и TDatabase в Delphi 6) можно запросить выполнение SQL -сервером фактически (почти?) любого SQL -оператора.

(**)Посмотреть поля, их свойства и события можно после «двойного Click» мышкой на объекте TDataSet (TTable или TQuery). Если появившееся окно редактирования полей пустое, то нажав правую кнопку мыши в контекстном меню выбрать Add All Fields.

 

(*) View – виртуальная, но постоянная таблица базы данных. Использование View в качестве рабочей временной таблицы – плохая идея. Однако ж в данном конкретном случае мы воспользуемся этой возможностью, дабы не усложнять проблемы...

(*) Международный стандарт ISO/IEC 12207, Стандарты комплекса ГОСТ 34, фирменные методики – MSF (MicroSoft Solution Framework), Oracle CDM (Custom Development Metod)...

§ Зиндер Е.С. Соотнесение и использование стандартов организации жизненных циклов систем. Журнал СУБД N 3, 1997.

§ Вендеров А.М. CASE-технология. М.:ФиC, 1998.-176 с.

§ Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD. С.Ф. Уилсон и др. М. 2002. –737 с.

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

Самитов Р.К.

БАЗЫ ДАННЫХ. (5-й семестр ВМК)

1. Информационные системы, базы данных и системы управления базами данных.

Информационная система (ИС):

· предназначена для сбора, хранения и обработки информации;

· ориентирована на конечного пользователя - непрограммиста.

Конкретная ИС всегда связана с конкретной областью применения - предметной областью:

· данные - информация этой области применения;

· процессы (действия над данными) - задачи этой предметной области;

· конечные пользователи - специалисты этой области (бухгалтера, библиотечные работники...).

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

База данных (БД): набор взаимосвязанных файлов данных, предназначенных для решения набора взаимосвязанных задач предметной области.

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

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

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

СУБД (в широком смысле) содержит:

· программный процессор баз данных (СУБД в узком смысле) - системное ядро, непосредственно реализующее операции с БД;

· средства разработки информационных систем;

· средства администрирования базы данных.

Назначение и состав СУБД - системного ядра:

 

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

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

Возможность обеспечить независимость по данным открывается благодаря тому, что:

· СУБД имеет информацию о структуре данных (из описания на DDL);

· операторы DML - языка, на котором пишутся прикладные программы, выполняет СУБД.

Технология обеспечения независимости по данным основана на концепции 3-х уровневого представления базы данных (ANSI/SPARC-1975):

· логический (средний) уровень: концептуальное представление базы данных (концептуальная схема БД) - описание структуры БД предметной области в целом, но без деталей физической структуры хранения;

· физический (нижний) уровень: внутреннее представление базы данных (внутренняя схема БД) - описание структуры хранения БД, включая методы доступа;

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

 

		Конечные пользователи
		Хранимая база данных

 

 

В рамках этой концепции различаются:

· физическая независимость - в пределах заданного концептуального представления можно вносить изменения во внутреннее представление БД с целью повысить эффективность работы системы в целом;

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

Пользователи информационных систем и, в общем случае, прикладных систем (Application):

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

· прикладные программисты и аналитики - проводят настройку режимов работы ИС и прав доступа пользователей, определяют внешние представления БД и разрабатывают прикладные программы, расширяющие функциональное наполнение ИС;

· системные программисты и администраторы - проводят конфигурирование системной среды, в которой работает ИС, в частности - определяют объемы и размещение доступных ИС ресурсов памяти; настраивают внутреннее представление БД для более эффективной работы комплекса в целом...

2. Архитектура программных систем обработки баз данных (DataBase Applications).

Системное программное обеспечение (СПО) доступа к БД:

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

§ в более общем случае – Run-Time ядро СУБД.

Две причины усложнения СПО доступа к БД:

§ Многопользовательское предназначение данных. Много пользователей решают много задач. А много задач на сети требуют одновременного доступа к данным на общей БД.

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

§ Гетерогенность. По происхождению – данные могут поступать из разных источников. Различные программы, с помощью которых эти данные готовили, могли использовать свои различные способы представления.

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

В простых ситуациях «Программа в целом» может иметь вид цельного загрузочного модуля (.EXE), СПО доступа к БД включено в состав этого загрузочного модуля.

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

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

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

§ Сервер баз данных. Сервер БД – программный комплекс типа Run-Time ядра СУБД, функционирующий как отдельный независимый загрузочный модуль, отдельная независимая задача в операционной системе. Сегодня наиболее распространены SQL -сервера, которые (вполне адекватно) можно понимать как процессор команд обработки БД – операторов языка SQL (Structured Query Language).

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

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

§ Программные средства связи (*).

ODBC (Open Database Connectivity) – стандарт «открытого доступа к БД». ODBC- компоненты обеспечивают средства для связи прикладных программных систем с SQL -серверами БД. Использование ODBC не просто облегчает решение проблем связи, но и позволяет обеспечить высокий уровень независимости прикладной системы от конкретных SQL -серверов и их форматов представления БД.

BDE (Borland Database Engine) - это, по сути, низкоуровневое Run-time ядро СУБД. Оформлено оно в виде комплекса DLL- библиотек, на основе которых построены настольные СУБД Borland - Paradox, dBase и др., и на основе которых программные продукты Borland связываются с базами данных других СУБД.

3. Средства обработки БД.

База данных содержит файлы - ПОСТАВЩИКИ, ДЕТАЛИ, ДОГОВОРА, ПОСТАВКИ.

Файл ПОСТАВЩИКИ (PSTS) имеет поля - код поставщика (KPST - уникальный ключ), наименование поставщика (IMPST), адрес поставщика (ADRPST).

Файл ДЕТАЛИ (DET) имеет поля - код детали (KDET - уникальный ключ), наименование детали (IMDET), цвет детали (CVET).

Файл ДОГОВОРА (DOG) содержит сведения о том «кто» - «что» - «в каком количестве» обязался поставить, и имеет поля - код поставщика (KPST), код детали (KDET), количество (KOL), дата начала договора (DTN), дата завершения договора (DTK). (KPST, KDET) – уникальный (составной) ключ этого файла.

В период действия договора поставщик поставляет детали не обязательно «все за раз», а обычно партиями. Файл ПОСТАВКИ (PST) содержит сведения о партиях поставленных деталей: «кто» - «что» - «в каком количестве» - «когда» поставил, и имеет поля - код поставщика (KPST), код детали (KDET), количество (KOL), дата поставки (DTP). (DBLEC\DBLEC.ER1)

 

Задача. Сформировать список крупных (в количестве > 1000) поставок детали с кодом 1010: наименование поставщика, размер поставки.

3.1. Set- ориентированные средства обработки БД. Язык структурированных запросов SQL (Structured Query Language).

Дополнительный учебный материал по этой теме можно взять: Сетевое окружение > NTSERVER\PROGRAM\SRKDOC\ в каталогах INF(3S)\ и DB(5S)\

Ниже рассматриваются только избранные средства языка SQL в синтаксисе InterBase SQL (имеются небольшие отклонения от стандарта).

Базовые типы данных.

¨ CHAR(k) и VARCHAR(k) – строковый тип, соответственно фиксированной длины k и переменной длины £ k (VARCHAR(k) ~ string[ k ] в Паскаль).

¨ INTEGER – целочисленный тип.

¨ NUMERIC(k,m) – вещественный тип в форме с фиксированной точкой (k,m – ширина и точность, как в форматах вывода Паскаль).

¨ DATE и TIMESTAMP – тип дата-время.

Ключи таблиц.

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

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

¨ Первичный ключ (PRIMARY KEY)– выделенный уникальный ключ таблицы. В качестве первичного может быть объявлен любой уникальный ключ, но только один.

Межтабличные связи и ключи. Межтабличную связь можно объявить только для пары таблиц (бинарную) и только типа (1:N) – (Родительская таблица: Дочерняя таблица).

Связь определяется с помощью пары ключей: родительский ключ (REFERENCES) – один из уникальных ключей родительской таблицы (чаще всего, это ее первичный ключ), внешний ключ (FOREIGN KEY) – ключ дочерней таблицы (как правило, это неуникальный ключ).

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

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

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

Связь объявляется при дочерней таблице

§ поэтому внешний ключ (FOREIGN KEY) содержит ее же поля;

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

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

Ограничения целостности можно классифицировать.

¨ Внутритабличные горизонтальные. Каждая строка таблицы (или конкретное поле каждой строки) должна удовлетворять объявленному условию: заданному обычным логическим выражением (CHECK) или специальными, например NOT NULL – поле должно иметь непустое значение (*).

¨ Внутритабличные вертикальные. Набор значений в конкретном списке колонок таблицы (конкретного списка полей по всем строкам) должен удовлетворять условию неповторяемости - UNIQUE, PRIMARY (влечет UNIQUE);

¨ Межтабличные (ограничения ссылочной целостности). Для каждой строки дочерней таблицы межтабличной связи, если значение ее внешнего ключа не NULL, то должна существовать строка в соответствующей родительской таблице с таким же значением родительского ключа.

Стратегии поддержания ссылочной целостности. Существуют две основные стратегии поддержания ссылочной целостности.

¨ RESTRICT (ОГРАНИЧИТЬ) - не разрешать выполнение операции, приводящей к нарушению ссылочной целостности. Это самая простая стратегия, требующая только проверки, для строки дочерней таблицы имеется ли соответствующая строка в родительской таблице.

¨ CASCADE (КАСКАДИРОВАТЬ) - разрешить выполнение требуемой операции, но внести при этом необходимые поправки в других таблицах так, чтобы не допустить нарушения ссылочной целостности и сохранить все имеющиеся связи. Изменение начинается в родительской таблице и каскадно выполняется в дочерней таблице. В реализации этой стратегии имеется одна тонкость, заключающаяся в том, что дочерняя таблица сама может быть родительской для некоторой третьей таблицы. При этом может дополнительно потребоваться выполнение какой-либо стратегии и для этой связи и т.д. Если при этом какая-либо из каскадных операций (любого уровня) не может быть выполнена, то необходимо отказаться от первоначальной операции и вернуть базу данных в исходное состояние. Это самая сложная стратегия, но она хороша тем, что при этом не нарушается связь между строками родительской и дочерней таблиц.

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