А.С.Грошев.Базы данных.Уч.пособие

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

Начиная с 80-х годов одновременно с широким распространением персональных компьютеров большое распространение получили реляционные СУБД, такие, как dBase, FoxBase (его более поздние версии – FoxPro и Visual FoxPro), Paradox, Access. Наиболее распространенным форматом таблиц реляционных баз стал *.dbf, с которым работали dBase, FoxBase, а также Clipper – система написания программ (в режиме строкового компилятора) для работы с базами данных.

Рис. 1.9. Схема реляционной базы данных

В локальных сетях крупных информационных систем используются серверы баз данных Microsoft SQL Server, Oracle, DB2 UDB, Informix и др.,

также имеющие в основе баз реляционную модель.

Постреляционные базы данных

В настоящее время известны также так называемые «постреляционные» СУБД, в основе которых лежит модель данных в виде многомерных таблиц, (например в системе Caché фирмы InterSystems Сorporation) и широ-

21

кое использование принципов объектно-ориентированного подхода при организации баз данных и программировании.

1.3.4.Серверы баз данных

Влокальных и глобальных компьютерных сетях широко применяются серверы – компьютеры и программные средства для обслуживания клиентов

–рабочих станций и/или других серверов.

Примерами серверов могут быть:

файловый сервер, поддерживающий общее хранилище файлов для всех рабочих станций;

интернет-сервер, обеспечивающий предоставление информации в глобальной сети Интернет;

почтовый сервер, обеспечивающий работу с электронной почтой;

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

Термин «сервер баз данных» обычно используют для обозначения всей СУБД, основанной на архитектуре «клиент-сервер», включая и серверную, и клиентскую части. Наиболее распространенными серверами являются в на-

стоящее время Microsoft SQL Server, Oracle, IBM DB2 Universal DataBase.

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

1.3.5. Распределенные базы данных

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

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

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

22

ются в среде языка SQL. Возможность использования SQL основывается на обеспечении System R* прозрачности местоположения данных. Система автоматически обнаруживает текущее местоположение упоминаемых в запросе пользователя объектов данных; одна и та же прикладная программа, включающая предложения SQL, может быть выполнена в разных узлах сети. При этом в каждом узле сети на этапе компиляции запроса выбирается наиболее оптимальный план выполнения запроса в соответствии с расположением данных в распределенной системе.

23

1.4.Разработка концептуальной модели базы данных

1.4.1.Общее описание примера информационной системы «Контингент студентов университета»

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

Главная таблица базы данных – список студентов, содержащая, как минимум, следующие данные:

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

2.фамилия, имя и отчество;

3.дата поступления в университет;

4.факультет;

5.специальность;

6.курс;

7.номер группы;

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

Некоторые детали, касающиеся перечисленных данных:

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

п. 3 – в нашей стране наиболее часто используется формат работы с датой в виде ДД.ММ.ГГ, что совпадает с немецким (German) форматом дат. Количество цифр года – может быть два – для новых систем, поддерживающих заданный в Microsoft Windows годичный интервал (Панель управления – Язык и стандарты – Дата – ―При вводе двух цифр года воспринимать их как год между…‖) или для систем, в которых аналогичный интервал может быть задан в программе, либо 4 цифры;

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

24

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

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

1.номер зачетной книжки;

2.номер семестра;

3.предмет;

4.полученная оценка;

5.дата получения оценки;

6.фамилия преподавателя.

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

Также возможно создание справочника преподавателей для занесения их фамилии в таблицу оценок из этого справочника.

1.4.2. Использование системы CASE Studio для проектирования концептуальной и физической модели

Схему концептуальной модели можно создать с использованием системы CASE Studio. Данная система является профессиональным инструментом проектирования баз данных. Она предназначена для визуального создания и модификации диаграмм сущность-связь (ERD) и диаграмм потоков данных (DFD). Для разработанных диаграмм далее может быть сгенерирован программный код для создания таблиц, индексов, связей и других компонен-

тов различных СУБД (Oracle, DB2, MS SQL Server, Interbase, MySQL, PostgreSQL, Sybase, Ingres, Informix, Clipper и пр.). Кроме того, предусмотре-

на возможность генерации ER-диаграмм для существующей базы данных (Reverse Engineering) с использованием для связи с БД ODBC, ADOдрайверов или прямого соединения.

При создании новой модели данных следует задать, для какой СУБД она проектируется, т. к. CASE Studio использует индивидуальные свойства каждой БД на стадии построения диаграмм – типы и свойства атрибутов (стандартные БД и пользователя), возможности описания ключей (первичные и внешние), связей, условий соблюдения ссылочной целостности, пользователей и их групп (ролей); возможности написания хранимых процедур и пр. Таким образом, вместо класической ER-диаграммы в CASE Studio используется модель базы данных с описанием всех возможных ее свойств.

25

На рис. 1.10 покзана ERD для разобранного в п. 1.4.1 примера, на рис. 1.11 – режим описания свойств сущности.

Рис. 1.10. Пример ER-диаграммы в CASE Studio

Рис. 1.11. Окно описания свойств сущности

26

В прил. 1.1 и 1.2 приведены тексты сгенерированного кода для СУБД

Oracle и Access.

Задание № 1.1

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

личная карточка работника – форма № Т-2 (утверждена постановлением Госкомстата РФ от 29.12.2000 № 136);

справка о доходах физического лица и едином социальном налоге (взносе) – форма 2-НДФЛ (приказ МНС РФ от 30 октября 2001 г. N БГ- 3-04/458);

индивидуальная карточка учета сумм начисленных выплат и иных вознаграждений, а также сумм начисленного единого социального налога (взноса) – форма 1-НДФЛ (приказ МНС N БГ-3-04/458);

налоговая карточка по учету доходов и налога на доходы физических лиц – форма по приказу МНС РФ от 21 февраля 2002 г. N БГ-3-05/91;

формы отчетности по единому социальному налогу (приказ МНС от 29 декабря 2003 г. N БГ-3-05/722)

платежное поручение;

счет-фактура;

карточка учета материалов на складе и т.п.

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

27

Приложение 1.1 Сгенерированная Case Studio SQL-программа создания таблиц базы данных для сервера Oracle

Create table "Spisok" ( "NZ" Char(7) NOT NULL , "FIO" Char(45) NOT NULL , "data_p" Date,

"n_fclt" Number NOT NULL , "n_spect" Number NOT NULL , "kurs" Number NOT NULL , "n_grup" Char(3) NOT NULL , "n_pasp" Char(10))

/

Create table "Ocenki" ( "NZ" Char(7) NOT NULL , "semestr" Number,

"n_predm" Number NOT NULL , "ball" Char(1),

"data_b" Date, "prepod" Number)

/

Create table "Fclt" (

"n_fclt" Number NOT NULL , "name_f" Char(120))

/

Create table "Spect" ( "n_spect" Number NOT NULL , "name_s" Char(120))

/

Create table "Predmets" ( "n_predm" Number NOT NULL , "name_p" Char(120))

/

Alter table "Spisok" add primary key ("NZ")

/

Alter table "Fclt" add primary key ("n_fclt")

/

Alter table "Spect" add primary key ("n_spect")

/

Alter table "Predmets" add primary key ("n_predm")

/

Alter table "Ocenki" add foreign key ("NZ") references "Spisok" ("NZ") on delete cascade

/

Alter table "Spisok" add foreign key ("n_fclt") references "Fclt" ("n_fclt") on delete cascade

/

Alter table "Spisok" add foreign key ("n_spect") references "Spect" ("n_spect") on delete cascade

/

Alter table "Ocenki" add foreign key ("n_predm") references "Predmets" ("n_predm") on delete cas-

cade

/

-- Update trigger for Spisok

Create Trigger "tu_Spisok" after update of "NZ","n_fclt","n_spect"

on "Spisok"

referencing new as new_upd old as old_upd for each row

28

declare numrows integer; begin

-- cascade child Ocenki update when parent Spisok changed if (:old_upd."NZ" != :new_upd."NZ") then

begin

update "Ocenki"

end; end if;

-- restrict parent Spect when child Spisok updated if :new_upd."n_spect" != :old_upd."n_spect" then

begin

select count( * ) into numrows from "Spect"

where :new_upd."n_spect" = "Spect"."n_spect"; if ( numrows = 0 ) then

begin

RAISE_APPLICATION_ERROR(-20002,'Parent does not exist. Cannot update child.'); end;

end if; end;

end if;

-- restrict parent Fclt when child Spisok updated if :new_upd."n_fclt" != :old_upd."n_fclt" then

begin

select count( * ) into numrows from "Fclt"

where :new_upd."n_fclt" = "Fclt"."n_fclt"; if ( numrows = 0 ) then

begin

RAISE_APPLICATION_ERROR(-20002,'Parent does not exist. Cannot update child.'); end;

end if; end;

end if; end;

/

-- Update trigger for Ocenki

Create Trigger "tu_Ocenki" after update of "NZ","n_predm"

on "Ocenki"

referencing new as new_upd old as old_upd for each row declare numrows integer;

begin

-- restrict parent Predmets when child Ocenki updated if :new_upd."n_predm" != :old_upd."n_predm" then

begin

select count( * ) into numrows from "Predmets"

where :new_upd."n_predm" = "Predmets"."n_predm"; if ( numrows = 0 ) then

begin

RAISE_APPLICATION_ERROR(-20002,'Parent does not exist. Cannot update child.'); end;

end if; end;

end if;

-- restrict parent Spisok when child Ocenki updated if :new_upd."NZ" != :old_upd."NZ" then

begin

select count( * ) into numrows from "Spisok"

where :new_upd."NZ" = "Spisok"."NZ"; if ( numrows = 0 ) then

29

begin

RAISE_APPLICATION_ERROR(-20002,'Parent does not exist. Cannot update child.'); end;

end if; end;

end if; end;

/

-- Update trigger for Fclt

Create Trigger "tu_Fclt" after update of "n_fclt"

on "Fclt"

referencing new as new_upd old as old_upd for each row declare numrows integer;

begin

-- cascade child Spisok update when parent Fclt changed if (:old_upd."n_fclt" != :new_upd."n_fclt") then

begin

update "Spisok"

end;

/

-- Update trigger for Spect

Create Trigger "tu_Spect" after update of "n_spect"

on "Spect"

referencing new as new_upd old as old_upd for each row declare numrows integer;

begin

-- cascade child Spisok update when parent Spect changed if (:old_upd."n_spect" != :new_upd."n_spect") then

begin

update "Spisok"

end;

/

-- Update trigger for Predmets

Create Trigger "tu_Predmets" after update of "n_predm"

on "Predmets"

referencing new as new_upd old as old_upd for each row declare numrows integer;

begin

-- cascade child Ocenki update when parent Predmets changed if (:old_upd."n_predm" != :new_upd."n_predm") then

begin

update "Ocenki"

end;

/

-- Insert trigger for Spisok

Create Trigger "ti_Spisok" after insert on "Spisok"

referencing new as new_ins for each row declare numrows integer;

begin

-- restrict child Spisok when parent Spect insert if (:new_ins."n_spect" is not null) then

begin

30