Информационная система
«Электронный архив»
Архитектура и системные требования (спецификация)
©
История исправлений и дополнений
Дата
Версия
Описание
Автор
01.05.2005
0.5
Исходная версия
20.06.2009
1.0
Проведены реструктуризация и дополнение документа с учетом рекомендаций, предложенных в книгах И. Соммервилла и Д. Леффингуэлла (их библиографические описания см. ниже)
01.05.2010
1.1
Добавлены новые модули; произведен отказ от фреймовой организации окна браузера
01.03.2011
1.2
Уточнена архитектура программной системы. Добавлены модули экспорта и импорта в группу вспомогательных модулей
Примечание. Дата выпуска версии 0.5 – приблизительная.
1. Введение
1.1. Цель документа
Цель данного документа состоит в описании высокоуровневой архитектуры программного продукта и распределении функций и требований по его подсистемам.
1.3. Ссылки и использованная литература
1.3.1. Список документов, упоминаемых в документе «Архитектура и системные требования»
1. Документ-концепция.
1.3.2. Список источников, к которым можно обратиться за справками в процессе разработки
1. Стандарты:
– ГОСТ 7.1–2003 «СИБИД. Библиографическая запись. Библиографическое описание. Общие требования и правила составления»;
– ГОСТ 7.11–2004 «СИБИД. Библиографическая запись. Сокращение слов и словосочетаний на иностранных европейских языках»;
– ГОСТ 7.12–93 «СИБИД. Библиографическая запись. Сокращение слов на русском языке. Общие требования и правила»;
– ГОСТ 7.60–90 «СИБИД. Издания. Основные виды. Термины и определения»;
– ГОСТ 7.80–2000 «СИБИД. Библиографическая запись. Заголовок. Общие требования и правила составления»;
– ГОСТ 7.82–2001 «СИБИД. Библиографическая запись. Библиографическое описание электронных ресурсов. Общие требования и правила составления»;
– ОСТ 29.130-97 «Издания. Термины и определения».
2. Система автоматизации библиотек ИРБИС. Общее описание системы [Текст]. – М. : ГПНТБ России, 2002. – 260 с.
1.3.3. Список использованной литературы
1. Соммервилл, И. Инженерия программного обеспечения [Текст] / Иан Соммервилл ; пер. с англ. [и др.] ; под ред. . – 6-е изд. – М. ; СПб. ; Киев : Вильямс, 2002. – 624 с. : ил. – Библиогр.: с. 603–, 35 назв.). – Предм. указ.: с. 618–623. – Парал. тит. англ. – Перевод изд.: Software engineering / Ian Sommerville. 6th ed. London [etc.] : Pearson Education, 2001. – 3500 экз. – ISBN -0 (рус.). – ISBN -X (англ.).
2. Леффингуэлл, Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход [Текст] / Дон Леффингуэлл, Дин Уидриг ; пер. с англ. и ред. . – М. : Вильямс, 2002. – 446, [2] с. : ил. – Парал. тит. англ. – Прилож.: с. 369–438. – Библиогр.: с. 439–440. – Предм. указ.: с. 441–445. – Перевод изд.: Leffingwell, Dean. Managing Software Requirements. A Unified Approach / Dean Leffingwell, Don Widrig. Boston : Addison-Wesley, [2000]. – 3500 экз. – ISBN -4 (рус.). – ISBN -2 (англ.).
2. Архитектура программного продукта и модульный состав
подсистем
2.1. Архитектура программного продукта
Архитектура программного продукта представлена на рис. 1. Основной программной подсистемой является пользовательская подсистема. Состав модулей и управляющие связи пользовательской подсистемы (т. е. иерархия вызовов модулей) показаны на рис. 2. В качестве модели управления выбрана модель централизованного управления (модель «вызов–возврат»). Административная подсистема предназначена для управления полномочиями доступа различных пользователей к базе данных из программных модулей. Эта подсистема опирается на группу так называемых административных таблиц базы данных. В этих таблицах хранятся метаданные о пользователях программного продукта. При запуске каждого модуля пользовательской подсистемы выполняется проверка полномочий доступа конкретного пользователя именно на основе этих таблиц. Подсистема конфигурирования предназначена для настройки программного продукта в соответствии с потребностями пользователя. Параметры конфигурации сохраняются в текстовых файлах. Важную роль играет библиотека функций (процедур). Она содержит типовые процедуры для выполнения основных задач по работе с базой данных (ввод записи в таблицу, обновление и удаление записей), процедуры для формирования SQL-операторов на основе данных, введенных пользователем в поля формы в окне браузера, процедуру для считывания конфигурационных параметров, процедуры проверки полномочий пользователя и другие процедуры.
В базе данных создается три схемы: public (по умолчанию) – это основная схема, схема «экспорт/импорт» и схема «импорт». Схема public представлена на рис. 1. Таблицы этой схемы условно разделены на три группы. Кроме административных таблиц есть также справочные таблицы, предназначенные для хранения справочных данных (персоналии, издательства и др.), и основные таблицы, предназначенные для хранения библиографических описаний и их элементов. Все три группы таблиц базы данных разделены на два класса: рабочие таблицы и журнальные таблицы. В рабочих таблицах хранится текущая версия данных, с этими таблицами работает пользователь, он получает данные именно из этих таблиц. Журнальные таблицы предназначены для хранения истории изменений данных в рабочих таблицах. При выполнении операций обновления и удаления данных, содержащихся в рабочих таблицах, происходит также запись измененных версий этих данных в соответствующие журнальные таблицы. Журнальная таблица существует для каждой рабочей таблицы и содержит все ее поля, а также ряд дополнительных служебных полей.
Рис. 1. Архитектура программного продукта
В схемах «экспорт/импорт» и «импорт» создаются точные копии справочных и основных таблиц схемы public, копии административных таблиц не создаются. При этом создаются только рабочие таблицы, а журнальные – нет. Под копией таблицы подразумевается копия определения таблицы, а не копия ее содержимого. На рис. 1 схемы «экспорт/импорт» и «импорт» не показаны.
Справочная подсистема должна быть контекстно-чувствительной. Должны быть предусмотрены средства интернационализации (I18n) и локализации (L10n). Предполагается поддержка двух языков: русского и английского. Интерфейс пользователя реализуется с помощью Web-браузера.
Для облегчения и ускорения процессов ввода и вывода данных предназначены средства (процедуры) импорта и экспорта данных, представленных в виде SQL-операторов.
2.2. Модульный состав пользовательской подсистемы
Рис. 2. Структура вызовов модулей пользовательской подсистемы
На рис. 2 стрелками указаны направления вызовов модулей (от вызывающего модуля к вызываемому). Справочники вызываются не только из главного модуля, но также и из модулей, отвечающих за обработку элементов библиографического описания. Кроме того, справочники могут вызываться один из другого.
В состав справочников на рис. 2 входят:
1. Валюты
Книги могут быть приобретены не только за рубли, но и за другие валюты.
2. Виды заглавий
Согласно ГОСТ 7.1–2003 возможны заглавия различных видов: основное, параллельное и др.
3. Виды мероприятий
Это относится к научным мероприятиям: конференция, симпозиум и др.
4. Виды признаков объектов библиографического описания
Согласно ОСТ 29.130–97: научное издание, учебное издание и др. Эта информация может быть полезной при формировании списков литературы по различным критериям: например, учебной литературы.
5. Виды справочных материалов
В состав справочного аппарата изданий могут входить различные указатели (предметный, именной и др.), примечания и т. д.
6. Виды стандартных номеров (ISBN, ISSN и др.)
Есть еще авторский знак, коды УДК и ББК.
7. Виды статуса мероприятий
Это относится к научным мероприятиям, например, конференциям: всероссийская, международная, региональная и т. д.
8. Виды тиражей
Основной тираж, допечатка тиража.
9. Виды ученых степеней
Кандидат технических наук, доктор технических наук и т. д.
10. Виды характеристик объектов библиографического описания
Пользователь может самостоятельно назначить эти характеристики, например, сложность, полезность и т. д.
11. Виды языковой обработки элементов библиографических описаний
В оригинальном виде, в переводе, в транскрипции, в транслитерации. Это может быть нужно при описании иностранных книг или статей, когда, например, нет возможности сделать описание на языке оригинала (например, японском или китайском).
12. Города
Места издания книг, проведения конференций, местонахождения организаций и др.
13. Группы признаков объектов библиографического описания
Согласно ОСТ 29.130–97: виды изданий по целевому назначению, виды изданий по читательскому адресу и др.
14. Группы специфических обозначений материала
Печатные материалы, аудиоматериалы и др. Позаимствовано у АБИС «ИРБИС».
15. Каналы поступления
Откуда поступил объект (книга, журнал, файл и т. д.): куплен в книжном магазине, «добыт» в сети Internet, подарен и т. д.
16. Коды видов деятельности организаций, учреждений
Образовательная, научная и т. д.
17. Коды видов упаковки
Переплет, бумажная обложка и др.
18. Коды источников библиографического описания
Где взята информация для составления библиографического описания: из оригинального объекта, из списка литературы в другой книге, из прайс-листа книжного магазина и др.
19. Коды общего обозначения материала
Согласно ГОСТ 7.1–2003: текст, электронный ресурс, карты и др.
20. Коды физической формы, в которой присутствуют единицы хранения
В оригинальном виде, ксерокопия и др. Это необходимо для выяснения доступности, например, книг для чтения.
21. Научные специальности
Согласно номенклатуре Высшей аттестационной комиссии Министерства образования и науки России. Например, 05.13.01 «Системный анализ, управление и обработка информации».
22. Отрасли науки
Технические науки, экономические науки и т. д.
23. Роли
Роль (функция), в которой выступает персоналия или организация в данном издании, например, автор, редактор, переводчик и т. д.
24. Специфические обозначения материала
Страница (с.), лист (л.), электронно-оптический диск (электрон.-опт. диск) и др.
25. Страны
В базу данных могут попасть сведения о книгах, изданных за рубежом.
26. Типы связей между объектами библиографического описания
Том многотомного издания, перевод и т. д. Это может быть полезно при выявлении, например, оригинального издания и его переводов.
27. Языки
Русский, английский и др.
*28. Виды деятельности организаций, учреждений
Виды деятельности конкретных организаций, учреждений. Например, «Наука» – издательская, Московский государственный университет – образовательная и научная.
*29. Ключевые слова
Ключевые слова (ими также могут быть и целые словосочетания), назначенные книгам, статьям и другим объектам в качестве характерных признаков, отражающих их содержание, тематику излагаемого в этих источниках материала.
*30. Конференции, съезды, симпозиумы, семинары, выставки...
Описания конкретных конференций, съездов, симпозиумов, семинаров, выставок.
*31. Организации, учреждения, временные коллективы
Описания конкретных организаций, учреждений, временных коллективов: издательств, библиотек, вузов и др.
*32. Персоналии
Это все те люди, которые имеют отношение к объектам, описанным в базе данных: авторы, редакторы, владельцы интересующих нас книг и т. д.
Примечание. Знаком * обозначены важные справочники.
Наименования областей библиографического описания и элементов этих областей определены в ГОСТ 7.1–2003. В состав модулей, отвечающих за обработку элементов библиографического описания, на рис. 2 входят (наименования областей библиографического описания выделены курсивом, они не являются наименованиями модулей):
Область заглавия и сведений об ответственности
1. Заглавия
Издание может иметь более одного заглавия (например, параллельное заглавие).
2. Сведения об ответственности
Список всех лиц и/или организаций, принимавших участие в выпуске данного издания (авторы, редакторы, переводчики и др.).
Область издания
3. Сведения об издании
Например, издание 2-е, исправленное и дополненное (изд. 2-е, испр. и доп.).
Область специфических сведений
4. Электронные ресурсы
5. Сериальные документы
6. Нормативные документы (стандарты и ТУ)
Область выходных данных
7. Место издания, изготовления
Возможно более одного места издания для данного издания.
8. Издатель, изготовитель, распространитель
Возможно более одного издателя для данного издания.
9. Дата издания, печатания, изготовления
Область физической характеристики
10. Специфическое обозначение материала и объем; сопроводительный материал
Например, 254 с. : ил. (иллюстрации).
Область серии
11. Серии
Наименование серии или серий, в которые входит данное издание.
Область примечания
12. Примечания
В качестве примечаний выступают сведения о библиографических списках, о различных указателях (именном, предметном и др.), сведения об оригинальном иностранном издании (для переводных изданий) и т. д.
13. Тираж
Область стандартного номера и условий доступности
14. Стандартные номера (ISBN, ISSN, ...)
Для конкретного издания их может быть более одного, например, для оригинального иностранного издания и для русскоязычного переводного издания, для многотомного издания в целом и для отдельного тома.
15. Условия доступности
16. Цена
В состав модулей, отвечающих за обработку дополнительных сведений, относящихся к объектам библиографического описания, на рис. 2 входят:
Дополнительные библиографические сведения
17. Объекты-контейнеры
Этот модуль отвечает за формирование связи между аналитическим библиографическим описанием, например, научной статьи и библиографическим описанием конкретного выпуска (номера) научного журнала, в котором эта статья помещена. Еще одним примером является установление связи между библиографическим описанием многотомного издания в целом и библиографическими описаниями отдельных томов. Таким образом, объект-контейнер в приведенных примерах – это конкретный выпуск (номер) научного журнала и многотомное издание в целом. Наличие этого модуля должно упростить процедуру получения сведений, например, обо всех томах многотомного издания.
18. Языки текста
Текст издания может быть представлен на нескольких языках.
19. Признаки объекта
Признаки конкретного объекта (книги, журнала, электронного издания и др.) определяются на основе справочника «Виды признаков объектов библиографического описания».
Использование
20. Проработка содержания
Описание вида проработки (чтение текста, просмотр и т. д.) и даты проработки книги, статьи и т. д.
21. Общая характеристика
Общая характеристика проработанного издания, сведения о полезных фрагментах текста, заинтересовавших читателя (т. е. номера страниц), короткие цитаты.
22. Детальные характеристики
Виды таких характеристик выбирает сам пользователь из справочника «Виды характеристик объектов библиографического описания», оценки выставляются по 10-балльной шкале.
23. Ключевые слова
Ключевые слова, назначенные конкретному объекту. Они выбираются из справочника «Ключевые слова».
24. Содержание (оглавление)
Содержание (оглавление) может быть введено частично или полностью.
25. Справочные материалы
См. описание справочника «Виды справочных материалов»
26. Участие в группировках (списках)
Конкретный объект (книга, статья) может быть включен в различные тематические списки, например, список книг для подготовки курсовой работы по какой-либо дисциплине. В этом модуле можно просмотреть описания тематических списков, в которые включен данный объект, и включить объект в другие списки.
Наличие
27. Экземпляры (единицы хранения)
Могут быть описаны не только те экземпляры, которые хранятся у пользователя программного продукта, но также и экземпляры, хранящиеся в библиотеках.
В состав вспомогательных модулей на рис. 2 входят:
1. Описания временных группировок (списков) объектов библиографического описания
Это и есть тематические списки: описания и полные составы, т. е. перечни объектов, входящих в каждый список.
2. Экспорт данных.
Этот модуль предназначен для выполнения инициализации экспорта (т. е. подготовки специальной схемы базы данных), организации просмотра экспортированных данных и завершения экспорта (т. е. формирования экспортного текстового SQL-файла).
3. Импорт данных.
Этот модуль предназначен для выполнения инициализации импорта (т. е. подготовки специальной схемы базы данных и загрузки в нее данных из SQL-файла), организации просмотра импортируемых данных и завершения импорта (т. е. переноса записей из специальной схемы базы данных в основную схему).
3. Системные требования
3.1. Требования к программному продукту в целом
Пользовательские требования (см. документ-концепцию):
– ПФТ1. Соответствие требованиям ГОСТ 7.1–2003;
– ПНТ3. Аутентификация пользователей;
– ПНТ6. Организация коллективной работы.
При проектировании программного продукта необходимо учесть все пользовательские требования, приведенные в этом списке, даже если они не детализированы в системных требованиях.
СТ1. Организация доступа пользователя к идентификаторам объектов
1. Интерфейс пользователя и база данных должны быть организованы таким образом, чтобы пользователь имел возможность работать непосредственно с идентификаторами объектов, хранящихся в базе данных.
Обоснование. Это позволит в ряде случаев ускорить процесс ввода и корректировки данных за счет того, что в некоторых областях библиографического описания наиболее часто используется ограниченное множество объектов (это имеет место, например, для издательств), поэтому пользователь может запомнить идентификаторы этих объектов. Данный подход также позволит сделать более гибким процесс конфигурирования программного продукта за счет того, что в конфигурационном файле пользователь сможет указывать непосредственно идентификаторы, а не наименования объектов, тем самым будет устранена возможность описок.
3.2. Подсистема «Интерфейс пользователя»
Пользовательские требования (см. документ-концепцию):
– ПФТ7. Простые средства поиска информации;
– ПФТ10. Развитые средства помощи пользователю для ускорения ввода данных;
– ПФТ11. Развитые средства поиска информации.
При проектировании интерфейса пользователя необходимо учесть все пользовательские требования, приведенные в этом списке, даже если они не детализированы в системных требованиях.
Данная подсистема не состоит из конкретных модулей. Она является, условно говоря, виртуальной, поскольку весь интерфейс формируется динамически модулями программной пользовательской подсистемы, которая отвечает также и за взаимодействие с базой данных. Модулей, которые предназначены только для формирования интерфейса пользователя, не предусмотрено.
СТ2. Общая схема организации интерфейса пользователя
1. Необходимо отказаться от использования фреймовой структуры организации окна браузера. В верхней части окна должна содержаться информация о командах, доступных пользователю. Нижняя часть окнам предназначена для ввода и вывода данных, т. е. для визуализации данных, извлеченных по запросу пользователя из базы данных, либо для организации HTML-формы для запроса новых данных у пользователя.
Обоснование. В версии HTML 5 фреймы не поддерживаются.
СТ3. Гибкая схема работы пользователя при вводе данных
1. Необходимо предусмотреть возможность вызова модулей-справочников при вводе данных в основные таблицы базы данных. При этом пользователь должен иметь возможность ввести требуемые данные в окно HTML-формы посредством осуществления выбора из списка, сформированного модулем-справочником.
2. Необходимо предоставлять пользователю также и возможность работы непосредственно с идентификаторами объектов, представленных в базе данных (например, вводить непосредственно идентификатор издательства или идентификатор автора).
3. Необходимо предусмотреть возможность использования значений «по умолчанию». Такие значения пользователь может ввести в конфигурационный файл.
4. Необходимо для большинства полей предусмотреть возможность формирования коротких списков, состоящих из наиболее часто используемых значений, вводимых пользователем в это поле. Например, для поля с условным названием «Фамилия, имя, отчество персоналии» один список может содержать наиболее распространенные имена, а второй список – отчества. Особенностью этих списков является то, что они не хранятся в справочных таблицах базы данных, а формируются на основе конфигурационного файла (в который их вносит пользователь). Такие списки вызываются на экран с помощью HTML-ссылки. При работе с описанными списками пользователь просто выбирает нужное значение из списка, и оно копируется в то поле HTML-формы, для которого этот список предназначен.
Обоснование. Способ ввода непосредственно идентификаторов позволит сократить число манипуляций пользователя с «мышью» и клавиатурой при частом вводе ограниченного множества идентификаторов (например, если пользователь часто работает с книгами двух-трех издательств, то он может просто запомнить идентификаторы этих издательств).
СТ4. Индикация наличия данных в областях библиографического описания
1. Необходимо при выводе HTML-формы с библиографическим описанием выводить также знаки (признаки), показывающие наличие записей в таблицах базы данных, соответствующих областям библиографического описания (сведения об ответственности, место издания и т. д.).
2. Должно быть реализовано два подхода:
– «бинарный», т. е. такой, при котором пользователь видит только сам факт наличия таких записей, но не видит их количества, поэтому для получения сведений об их количестве пользователь должен запустить соответствующий модуль, ответственный за конкретную область библиографического описания;
– «количественный», при котором пользователь видит количество записей в каждой области библиографического описания.
Обоснование. Это позволит упростить получение информации о степени полноты ввода данных в области библиографического описания. Без реализации этого требования пользователю пришлось бы для получения информации о наличии в базе данных, например, сведений об ответственности или месте издания вызывать модули, ответственные за те или иные области библиографического описания, т. е. производить больше манипуляций с «мышью» и клавиатурой.
СТ5. Подтверждение деструктивных действий пользователя
1. При попытке пользователя выполнить одно из деструктивных действий, например, удаление записи из базы данных, должен быть выведен запрос на подтверждение этих действий.
Обоснование.
СТ6. Контекстно-зависимый способ активации/деактивации полей в HTML-формах
1. При вводе данных в поля HTML-форм необходимо запрещать (деактивировать поле) или разрешать (активировать поле) доступ к тем или иным полям в зависимости от значений данных, введенных пользователем в другие поля.
Обоснование.
3.3. Подсистема «Средства интернационализации и локализации»
См. документ-концепцию (п. 6.2.2.4).
3.4. Справочная подсистема
См. документ-концепцию (п. 7.3).
3.5. Административная подсистема
Пользовательские требования (см. документ-концепцию):
– ПНТ4. Интерактивная система управления разграничением полномочий доступа к базе данных.
При проектировании административной подсистемы необходимо учесть все пользовательские требования, приведенные в этом списке, даже если они не детализированы в системных требованиях.
СТ7. Предоставление полномочий пользователю на уровне отдельных процедур
модулей
1. Полномочия, предоставляемые конкретному пользователю, должны связываться с конкретными процедурами конкретных модулей.
Пример. Пользователю admin может быть предоставлено право выполнения процедуры корректировки библиографического описания, а пользователю test_user такое право может не быть предоставлено.
2. Необходимо использовать специальные приемы для сокращения числа записей в административных таблицах базы данных с целью упрощения как алгоритмов предоставления полномочий пользователю, так и алгоритмов обработки этих записей при выяснении объема полномочий пользователя.
Пример. Если необходимо предоставить пользователю право выполнять все процедуры во всех модулях, то это должно быть сделано путем ввода в специальную административную таблицу базы данных лишь одной записи с указанием специальных ключевых слов (например, «ALL») как для наименований модулей, так и для наименований процедур.
3. При попытке пользователя выполнить процедуру, на выполнение которой у него нет полномочий, должно быть выведено сообщение.
Обоснование. Предлагаемый подход будет служить дополнением к системе привилегий доступа к таблицам базы данных, которая (система) организуется средствами СУБД. Кроме того, это позволит избежать вывода системных сообщений, которые генерирует СУБД в случаях, когда у пользователя недостаточно полномочий доступа к таблицам. Вместо этого пользователь получит понятное ему сообщение о том, что у него нет полномочий для выполнения данной процедуры.
3.6. Библиотека функций (процедур)
Нет особых требований.
3.7. Пользовательская подсистема
Пользовательские требования (см. документ-концепцию):
– ПФТ3. Обработка наличия различных вариантов имен собственных;
– ПФТ7. Простые средства поиска информации;
– ПФТ10. Развитые средства помощи пользователю для ускорения ввода данных;
– ПФТ11. Развитые средства поиска информации;
– ПФТ12. Иерархическая система ключевых слов;
– ПФТ13. Формирование библиографического описания из элементарных данных.
При проектировании пользовательской подсистемы необходимо учесть все пользовательские требования, приведенные в этом списке, даже если они не детализированы в системных требованиях.
СТ8. Проверка полномочий пользователя перед выполнением каждой операции
1. Должна быть организована проверка полномочий пользователя перед выполнением каждой операции. При отсутствии таких полномочий следует выводить сообщение.
Обоснование.
СТ9. Вывод сообщений об ошибках
1. При выполнении операций с базой данных должны выводиться сообщения об ошибках при их возникновении.
Обоснование.
3.8. Подсистема конфигурирования
Пользовательские требования (см. документ-концепцию):
– ПНТ2. Конфигурирование программного продукта.
При проектировании подсистемы конфигурирования необходимо учесть все пользовательские требования, приведенные в этом списке, даже если они не детализированы в системных требованиях.
3.9. База данных
Пользовательские требования (см. документ-концепцию):
– ПФТ1. Соответствие требованиям ГОСТ 7.1–2003;
– ПФТ2. Ввод библиографических описаний в базу данных в готовом виде;
– ПФТ3. Обработка наличия различных вариантов имен собственных;
– ПФТ4. Фиксирование результатов проработки источников;
– ПФТ5. Хранение выписок из проработанных источников;
– ПФТ6. Система ключевых слов;
– ПФТ8. Учет экземпляров;
– ПФТ9. Формирование тематических библиографических списков;
– ПФТ12. Иерархическая система ключевых слов;
– ПНТ3. Аутентификация пользователей;
– ПНТ4. Интерактивная система управления разграничением полномочий доступа к базе данных;
– ПНТ5. Ведение журнала операций с базой данных;
– ПНТ6. Организация коллективной работы.
При проектировании базы данных необходимо учесть все пользовательские требования, приведенные в этом списке, даже если они не детализированы в системных требованиях.
СТ10. Состав таблиц базы данных
1. В базе данных должны быть предусмотрены таблицы для хранения следующих сведений:
– всех справочников согласно перечню модулей-справочников, приведенному в разделе 2.2 настоящего документа;
– сформированных библиографических описаний;
– результатов проработки источников;
– выписок из проработанных источников;
– иерархической системы ключевых слов;
– данных о сериях и подсериях;
– данных об экземплярах описанных объектов;
– тематических библиографических списков.
Обоснование.
СТ11. Разделение базы данных на группы таблиц
1. База данных должна быть условно разделена на следующие группы таблиц: административные таблицы, справочные таблицы и основные таблицы.
Примечание. К основным таблицам относятся те таблицы, которые не являются справочными или административными.
Обоснование. Это позволит лучше структурировать программные подсистемы.
СТ12. Поддержка иерархий объектов в базе данных
1. Должна быть предусмотрена возможность создания иерархий объектов в таблицах базы данных за счет введения в таблицы полей с условным названием «Идентификатор родительского объекта».
Обоснование. Такие иерархии могут возникать, например, при описании организаций (Российская академия наук имеет в своем подчинении ряд академических институтов; у издательств могут быть филиалы и т. д.).
СТ13. Использование согласованных правил именования полей и таблиц базы данных
1. Должна использоваться единая система именования полей таблиц и самих таблиц базы данных. Однотипные поля должны иметь префиксы и/или постфиксы (например, постфикс «_fname», т. е. full name, может означать полное имя объектов какого-либо типа, а постфикс «_sname», т. е. short name, – краткое имя).
Обоснование.
СТ14. Разграничение полномочий доступа пользователей к базе данных
1. В каждой таблице базы данных должны быть предусмотрены поля для хранения имени пользователя, выполнившего операцию с конкретной таблицей, и времени выполнения этой операции.
Обоснование.
3.10. Средства импорта и экспорта данных
Пользовательские требования (см. документ-концепцию):
– ПНТ1. Экспорт и импорт данных.
При проектировании базы данных необходимо учесть все пользовательские требования, приведенные в этом списке, даже если они не детализированы в системных требованиях.
4. Интерфейсы между подсистемами
4.1. Программные подсистемы ↔ база данных
1. Взаимодействие между программными подсистемами и базой данных организуется с помощью пакета Pg. pm, написанного на языке программирования Perl. Ранее этот пакет поставлялся в составе дистрибутива СУБД PostgreSQL (до версии 7.3). В программных модулях SQL-запросы к базе данных формируются в виде символьных строк, которые передаются системе управления базой данных (СУБД) с помощью специальных процедур, входящих в состав пакета Pg. pm.
4.2. Пользовательская подсистема ↔ административная подсистема
1. Взаимодействие между этими подсистемами является косвенным и организуется посредством вызовов процедур из библиотеки процедур, которая взаимодействует с административными таблицами базы данных.
4.3. Пользовательская подсистема ↔ подсистема конфигурирования
1. Взаимодействие между этими подсистемами является косвенным и организуется за счет обращения к библиотеке процедур, в состав которой входят процедуры, предназначенные для считывания конфигурационных файлов.
5. Глоссарий и список сокращений
5.1. Глоссарий
5.2. Список сокращений
АБИС – автоматизированная библиотечная информационная система
БД – база данных
ПНТ – пользовательское нефункциональное требование
ПФТ – пользовательское функциональное требование
СТ – системное требование
СУБД – система управления базами данных
I18n – internationalization (интернационализация)
L10n – localization (локализация)
