metBD (Учебное пособие), страница 12

Даталогическое проектирование.

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

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

Описание концептуальной схемы БД в терминах выбранной СУБД.

Описание внешних моделей в терминах выбранной СУБД.

Описание декларативных правил поддержки целостности базы данных.

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

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

Мы должны построить корректную схему БД, ориентируясь на реляционную модель данных.

Корректной назовем схему БД, и которой отсутствуют нежелательные зависимости между атрибутами отношений.

Процесс разработки корректной схемы реляционной БД называется логическим проектированием БД

Проектирование схемы БД может быть выполнено двумя путями:

путем декомпозиции (разбиения), когда исходное

В общем случае существуют два подхода к выбору состава и структуры пред­метной области:

Функциональный подход - он реализует принцип движения «от задач» и при­меняется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей кото­рых создается рассматриваемая БД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.

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

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

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

Пример описания предметной области

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

• уникальный шифр;

• название;

• фамилии авторов (могут отсутствовать);

• место издания (город);

• издательство;

• год издания;

• количество страниц;

• стоимость книги;

• количество экземпляров книги в библиотеке.

Книги могут иметь одинаковые названия, но они различаются по своему уникальному шифру (ISBN).

В библиотеке ведется картотека читателей.

На каждого читателя в картотеку заносятся следующие сведения:

• фамилия, имя, отчество,

• домашний адрес;

• телефон (будем считать, что у нас два телефона - рабочий и домашний);

• дата рождения.

Каждому читателю присваивается уникальный номер читательского билета.

Каждый читатель может одновременно держать на руках не более 5 книг. Чита­тель не должен одновременно держать более одного экземпляра книги одного названия.

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

• уникальный инвентарный номер;

• шифр книги, который совпадает с уникальным шифром из описания книг;

• место размещения в библиотеке.

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

• номер билета читателя, который взял книгу;

• дата выдачи книги;

• дата возврата.

Предусмотреть следующие ограничения на информацию в системе:

1. Книга может не иметь ни одного автора.

2. В библиотеке должны быть записаны читатели не моложе 17 лет.

3. В библиотеке присутствуют книги, изданные начиная с 1960 по текущий год.

4. Каждый читатель может держать на руках не более 5 книг.

5. Каждый читатель при регистрации в библиотеке должен дать телефон для связи: он может быть рабочим или домашним.

6. Каждая область знаний может содержать ссылки на множество книг, но каж­дая книга может относиться к различным областям знаний.

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

• библиотекари;

• читатели;

• администрация библиотеки.

При работе с системой библиотекарь должен иметь возможность решать следующие задачи: .

Принимать новые книги и регистрировать их в библиотеке.

Относить книги к одной пли к нескольким областям знаний.

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

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

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

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

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

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

Читатель должен иметь возможность решать следующие задачи:

1. Просматривать системный каталог, то есть перечень всех областей знаний, книги по которым есть в библиотеке.

2. По выбранной области знаний получить полный перечень книг, которые чис­лятся в библиотеке.

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

Для выбранного автора получить список книг, которые числятся в библиотеке.

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

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

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

Даталогическое проектирование.

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