Требования к базам данных: ГОСТ 34.321-96 Информационные технологии (ИТ). Система стандартов по базам данных. Эталонная модель управления данными, ГОСТ от 22 февраля 2001 года №34.321-96

Требования к организации базы данных

Комитет
CODASYL (COnference
DAta SYstems
Languages), Организация
пользователей IBM, Ассоциация
вычислительных машин (ACM)
сформулировали следующие требования
к организации баз данных.

1. Установление
   многосторонних связей

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

2. Производительность

БД
должна обеспечивать требуемую пропускную
способность запросов и требуемое время
отклика.

3. Минимальные
   затраты

Выбираются
методы организации, которые минимизируют
требования к внешней памяти.

4. Минимальная
   избыточность

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

5. Возможности
   поиска

Пользователь
БД может обращаться к ней со множеством
запросов некоторого типа.

6. Целостность

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

7. Безопасность
   и секретность

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

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

8. Связь
   с прошлым

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

9. Связь
   с будущим

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

10. Простота
    использования

Интерфейс
СУБД должен предполагать, что конечный
пользователь не имеет необходимых
знаний по теории баз данных.

3. Классификация бд

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

Централизованная
БД хранится в одной ЭВМ.

Распределенная
БД хранится на нескольких ЭВМ.

По
способу доступа к данным БД разделяется
на БД с локальным и удаленным доступом.

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

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

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

1. файл
   сервер

2. клиент
   сервер.

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

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

Сервер
Сервер хранение

обработка

Файлы БД Извлеченные данные

Рабочие станции Рабочие
станции

Рис.4.1.Технология
«Файл-сервер». Рис.4.2.Технология
«Клиент-сервер»

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

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

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

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

По
степени универсальности различают:

• Специализированные
  СУБД,

• СУБД
  общего назначения.

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

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

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

СУБД и основные требования к ним — Студопедия

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

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

Основные требования к СУБД.

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

С требованием целостности данных связано понятие транзакции.

Транзакция — это последовательность операций над БД, рассматриваемых как единое целое (то есть или все, или ничего). На пример, при оформлении заказа на определенный товар в системе нужно выполнить такие операции: регистрацию заказа и резервирование определенного количества товара, а также уменьшение данного товара на складе. Если на любом этапе изменения данных произойдет сбой, то целостность БД будет нарушена. Для предотвращения подобных нарушений вводится транзакция «Оформление заказа», в которой над БД либо должны произвестись все необходимые операции (товар продан, уменьшен его запас на складе), либо должен произойти возврат к исходному состоянию (товар не продан, его количество на складе не изменилось).

2. Актуальность хранимых данных. В любой момент времени информация, содержащаяся в БД, должна быть современной.

3. Многоаспектное использование данных — поступление информации из различных источников в единую БД и возможность ее использования любым отделом предприятия в соответствии с правами доступа и функциями.

4. Возможность модификации системы— возможность ее расширения и модификации данных, а также дополнение новыми функциями без ущерба для системы в целом.

5. Надежность — целостность БД не должна нарушаться при технических сбоях.

6. Скорость доступа — обеспечение быстрого доступа к требуемой информации.

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

СУБД обеспечивают надежное хранение больших объемов данных сложной структуры во внешней памяти компьютера и эффективный доступ к ним.

К основным функциям СУБД относятся:

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

• поддержание целостности данных и управление транзакциями;

• ведение системного журнала изменений в БД для обеспечения восстановления БД после технического или программного сбоя;

• реализация поддержки языка описания данных и языка запросов;

• обеспечение безопасности данных;

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

Требования к базе данных

Р абочее м есто

3-й корпус,

1025 123123

О м ГУ

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

•Индексные файлы для табельного номера сотрудника в первом файле.

•Индексные файлы для инвентарного номера сотрудника во втором файле.

•Индексные файлы для табельного и инвентарного номеров в третьем файле.

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

1.3.1 Неизбыточность и непротиворечивость данных

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

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

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

1.3.2Защита данных от программных и аппаратных сбоев

Все виды защиты должны обеспечиваться СУБД. Сбои бывают двух видов.

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

2.Физический сбой. Во время работы СУБД возникает аварийная ситуация, причиной которой может быть как ошибка в СУБД или ОС, так и сбой оборудования, и т.д. При этом СУБД может не успеть выполнить операции по преобразованию структуры БД, и многие данные могут быть потеряны. Что должна уметь СУБД?

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

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

1.3.3Мобильность прикладного программного обеспечения

Определение 1.2 Прикладной программой в БД зовется программа пользователя, взаимодействующая с БД посредством СУБД.

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

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

Замечание. Сформулированное свойство носит название принципа независимости данных. Оно же — мобильность прикладных программ.

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

Требования к реляционным базам данных — Студопедия

1) каждая таблица должна иметь уникальное имя;

2) столбцы одной таблицы должны иметь уникальные имена, поэтому порядок следования столбцов в таблице не имеет значения;

3) каждая строка таблицы должна быть уникальной, т.е. в одной таблице не может быть двух одинаковых строк;

4) в каждой ячейке таблицы может быть только одно значение;

5) в идеале каждое данное должно храниться в базе в единственном экземпляре, т.е. не должно быть избыточности и дублирования данных. На практике избыточность данных должна быть сведена к разумному минимуму;

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

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

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

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

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

Для каждой таблицы обязательно наличие первичного ключа.

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

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

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

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

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

— создать отдельную таблицу;

— перенести этот столбец и другие столбцы, которые (функционально или транзитивно) зависят от данного столбца, в новую таблицу;

— обеспечить наличие в новой таблице целочисленного столбца «ID» (т.е. если еще не было – добавить) в качестве первичного ключа;

-в исходную таблицу добавить столбец, в котором будут храниться значения «ID» из новой таблицы (такой столбец называется внешним ключом, желательно, чтобы его название заканчивалось на «_ID»).

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

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

Примечание. Подобным же образом можно обосновать необходимость использования трех таблиц для реализации связи «многие-ко-многим» в реляционной модели данных.

Шестое требование. Термин «целостность данных» относится к правильности и полноте информации, содержащейся в базе данных. При изменении содержимого базы данных (добавление, обновление, удаление) может произойти нарушение целостности содержащихся в ней данных. Например:

— для номера телефона не указано имя контакта;

— при добавлении нового имени контакту ему присвоен уже имеющийся у другого имени контакта идентификационный номер;

— для контакта указана несуществующая мелодия.

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

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

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

Целостность таблицы. В каждой таблице должен быть первичный ключ. Первичный ключ обязателен для заполнения.

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

Если в СУБД установлены вышеперечисленные условия целостности данных, то СУБД сама следит за их выполнением.

Критерии выбора СУБД при создании информационных систем

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

В данной статье по результатам анализа доступных источников, например [1-5],
делается попытка сформулировать требования или, иными словами, критерии при
выборе СУБД, приводится классификация требований/критериев. Очевидно, наиболее
простой подход при выборе СУБД основан на оценке того, в какой мере существующие
системы удовлетворяют основным требованиям создаваемого проекта информационной
системы. Более сложным и дорогостоящим вариантом является создание
испытательного проекта на основе нескольких СУБД и последующий выбор наиболее
подходящего из кандидатов. Но и в этом случае необходимо ограничивать круг
возможных систем, опираясь на некие критерии отбора. Вообще говоря, перечень
требований к СУБД, используемых при анализе той или иной информационной системы,
может изменяться в зависимости от поставленных целей. Тем не менее можно
выделить несколько групп критериев:

* Моделирование данных
* Особенности архитектуры и функциональные возможности
* Контроль работы системы
* Особенности разработки приложений
* Производительность
* Надежность
* Требования к рабочей среде
* Смешанные критерии

Рассмотрим каждую из этих групп в отдельности.

Моделирование данных.

* Используемая модель данных. Существует множество моделей данных;
самые распространенные — иерархическая, сетевая, реляционная,
объектно-реляционная и объектная. Вопрос об использовании той или иной модели
должен решаться на начальном этапе проектирования информационной системы.
* Триггеры и хранимые процедуры. Триггер — программа базы данных,
вызываемая всякий раз при вставке, изменении или удалении строки таблицы.
Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти
изменения будут приняты. Хранимая процедура – программа, которая хранится на
сервере и может вызываться клиентом. Поскольку хранимые процедуры выполняются
непосредственно на сервере базы данных, обеспечивается более высокое
быстродействие, нежели при выполнении тех же операций средствами клиента БД. В
различных программных продуктах для реализации триггеров и хранимых процедур
используются различные инструменты.
* Средства поиска. Некоторые современные системы имеют встроенные
дополнительные средства контекстного поиска.
* Предусмотренные типы данных. Здесь следует учесть два фактически
независимых критерия: базовые или основные типы данных, заложенные в систему,
и наличие возможности расширения типов. В то время как отклонения базовых
наборов типов данных у современных систем от некоего стандартного, обычно,
невелики, механизмы расширения типов данных в системах того или иного
производителя существенно различаются.
* Реализация языка запросов. Все современные системы совместимы со
стандартным языком доступа к данным sql-92, однако многие из них реализуют те
или иные расширения данного стандарта.

Особенности архитектуры и функциональные возможности.

* Мобильность. Мобильность – это независимость системы от среды, в
которой она работает. Средой в данном случае является как аппаратура, так и
программное обеспечение (операционная система).
* Масштабируемость. При выборе СУБД необходимо учитывать, сможет ли
данная система соответствовать росту информационной системы, причем рост может
проявляться в увеличении числа пользователей, объема хранимых данных и объеме
обрабатываемой информации.
* Распределенность. Основной причиной применения информационных
систем на основе баз данных является стремление объединить взгляды на всю
информацию организации. Самый простой и надежный подход — централизация
хранения и обработки данных на одном сервере. К сожалению, это не всегда
возможно и приходится применять распределенные базы данных. Различные системы
имеют разные возможности управления распределенными базами данных.
* Сетевые возможности. Многие системы позволяют использовать широкий
диапазон сетевых протоколов и служб для работы и администрирования.

Контроль работы системы

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

Особенности разработки приложений.

* Многие производители СУБД выпускают также средства разработки приложений
для своих систем. Как правило, эти средства позволяют наилучшим образом
реализовать все возможности сервера, поэтому при анализе СУБД стоит
рассмотреть также и возможности средств разработки приложений.
* Средства проектирования. Некоторые системы имеют средства
автоматического проектирования, как баз данных, так и прикладных программ.
Средства проектирования различных производителей могут существенно
различаться.
* Многоязыковая поддержка. Поддержка большого количества национальных
языков расширяет область применения системы и приложений, построенных на ее
основе.
* Возможности разработки web-приложений. При разработкеразличных
приложений зачастую возникает необходимость использовать возможности среды
internet. Средства разработки некоторых производителей имеют большой набор
инструментов для построения приложений под web.
* Поддерживаемые языки программирования. Широкий спектр используемых
языков программирования повышает доступность системы для разработчиков, а
также может существенно повлиять на быстродействие и функциональность
создаваемых приложений.

Производительность.

* Рейтинг tpc (transactions per cent). Для тестирования
производительности применяются различные средства, и существует множество
тестовых рейтингов. Одним из самых популярных и объективных является
tpc-анализ производительности систем. Фактически tpc анализ рассматривает
композицию СУБД и аппаратуры, на которой эта СУБД работает. Показатель tpc –
это отношение количества запросов обрабатываемых за некий промежуток времени к
стоимости всей системы.
* Возможности параллельной архитектуры. Для обеспечения параллельной
обработки данных существует, как минимум, два подхода: распараллеливание
обработки последовательности запросов на несколько процессоров, либо
использование нескольких компьютеров-клиентов, работающих с одной БД, которые
объединяют в так называемый параллельный сервер.
* Возможности оптимизирования запросов. При использовании
непроцедурных языков запросов их выполнение может быть неоптимальным. Поэтому
необходимо произвести процесс оптимизации запросов, т.е. выбрать такой способ
выполнения, когда по начальному представлению запроса путем его синтаксических
и семантических преобразований вырабатывается процедурный план выполнения
запроса, наиболее оптимальный при существующих в базе данных управляющих
структурах.

Надежность.

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

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

Требования к рабочей среде.

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

Смешанные критерии.

* Качество и полнота документации. К сожалению, не все системы имеют
полную и подробную документацию.
* Локализованность. Возможность использования национальных языков не
во всех системах реализована полностью.
* Модель формирования стоимости. Как правило, производители СУБД
используют определенные модели формирования стоимости. Например, стоимость
одного и того же продукта может существенно изменяться в зависимости от того,
сколько пользователей будет с ним работать.
* Стабильность производителя.
* Распространенность СУБД.

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

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

телеграм канал. Подпишись, будет полезно!

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

12

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

Множество пользователей информационных систем можно классифицировать различным образом.

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

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

несанкционированного доступа к данным.

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

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

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

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

13

•Система должна обеспечивать заданный уровень достоверности хранимой информации, обеспечивать ее непротиворечивость (обеспечивать целостность базы данных).

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

•Система должна обеспечивать возможность поиска и выборки информации по произвольной группе признаков.

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

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

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

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

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

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

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

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

14

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

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

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

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

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

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

•Централизованное управление данными дает возможность обеспечения

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

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

•Появляется возможность стандартизации структур хранения данных, методов работы с ними.

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

15

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

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

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

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

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

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

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

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

•интеграция (объединение) данных,

•централизованное управление данными и

•обеспечение взаимной независимости данных и использующих их

прикладных программ

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

Системные требования к серверу баз данных

Системные требования к серверу баз данных

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

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

По результатам нагрузочных тестов типового проекта были сформированы
конфигурации для сервера. Приведенных характеристик достаточно для стабильного
функционирования типового проекта. На серверах, которые участвовали в
тестировании, использовались операционная система Windows Server 2012
Standard и СУБД Oracle 11g.

Требования к каналам связи

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

При одновременной работе с типовым проектом 100 пользователей необходимая
ширина канала сервера баз данных:

Зависимость ширины канала от количества пользователей линейная.

См. также:

Подготовка серверной части СУБД
| Установка
настольного приложения «Форсайт. Аналитическая платформа»

Требования к базе данных Microsoft Access

Хорошо сформулированные требования к проекту помогут разработать вашу базу данных

Определение требований и принцип их работы

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

Вот несколько примеров требований к базе данных Access:

• Функция, управляемая пользователем: «Пользователь должен иметь возможность включать в себя общую сумму продаж каждого продавца.«
• Системное свойство: «Должна быть форма входа и ограничения прав пользователей».
• Ограничение приложения: «Весь код должен включать перехват ошибок».

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

+ Как вам подходит этап планирования базы данных.

Вот несколько примеров утверждений, которые НЕ являются требованиями приложения:

• Это описание слишком неоднозначно: «Создайте программу инвентаризации.«
• Ограничение программы базы данных: «Таблица деталей должна иметь отношение« многие к одному »с таблицей поставщика».

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

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

Требования для пользователя программы

Поскольку требования «специфичны для пользователя», это означает, что разработчики не должны нести ответственность за создание требований к программе.Разработчик приложения обычно делает
не знать бизнес-среду или отрасль пользователя. Требования лучше всего разрабатывать на основе отзывов пользователей, и разработчики должны постоянно спрашивать: «Что вы хотите от окончательного приложения?
делать для вас? »

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

Вам нужна срочная помощь? Позвоните нам по номеру 512-202-7121 для быстрого обслуживания.

.

Требования к базе данных — BMC TrueSight Capacity Optimization 10.7

.

Требования к базе данных Oracle для ArcGIS 10.7.x и ArcGIS Pro 2.3 и 2.4 — Системные требования

Посетите службу поддержки Esri, чтобы получить информацию о политике среды, поддерживаемой Esri.

Поддерживаемые версии базы данных

Следующие выпуски Oracle являются минимальными сертифицированными исправленными версиями, поддерживаемыми ArcGIS. Более новые исправления Oracle для этих версий, включая уровни наборов исправлений и промежуточные (одноразовые) исправления, поддерживаются, но не сертифицированы.

Щелкните здесь информацию о поддерживаемых исправлениях для баз данных Oracle

Standard / Standard One / Enterprise Editions:

Oracle 11g R2 (64 bit) 11.2.0.4

Standard 2 (SE2) / Enterprise (EE) Editions:

Oracle 12c R1 (64 бит) 12.1.0.2

Oracle 12c R2 (64 бит) 12.2.0.1

Oracle 18c (64 бит) 18.3.0.0.0, 18.4.0.0.0

Oracle 19c (64 бит) 19.3.0.0 .0— Поддержка Oracle 19c начинается в ArcGIS Pro 2.4.2. Oracle 19c поддерживается ArcGIS 10.7.x, если вы устанавливаете ArcGIS (Desktop, Engine, Server) Support for Oracle 19c Patch

Поддерживаемые операционные системы

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

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

Дополнительные требования к библиотеке форм ST_Geometry

Esri поддерживает следующие четыре операционные системы, когда вы используете библиотеку форм ST_Geometry и настраиваете внешнюю процедуру Oracle (extproc). В списке указаны минимальные версии операционной системы, если минимальная версия, поддерживаемая Esri, отличается от поддерживаемой базами данных Oracle.

• IBM AIX (64-разрядная версия) — для Oracle 11.2.0.4 минимальный поддерживаемый
  версия — IBM AIX 6.1.0.0.
• Linux (64-разрядная версия) — для Oracle 11.2.0.4, минимально поддерживаемый
  версия — Red Hat Enterprise Linux AS / ES 5 — обновление 11.
• Solaris (64 бит) — для Oracle 11.2.0.4 минимальный поддерживаемый
  версия — Solaris 10 SPARC.
• Microsoft Windows (64-разрядная версия)

В Windows вам понадобится последняя версия распространяемого пакета Microsoft Visual C ++ для Visual Studio 2017, установленная на компьютере с базой данных Oracle.
См. Https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads
Чтобы получить больше информации.

• Поддержка Oracle Linux основана на документации Oracle о том, что Oracle Linux совместим — как исходный, так и двоичный — с Red Hat Enterprise Linux Server. См. FAQ по Oracle Linux на веб-сайте Oracle.
• Поддержка Oracle Exadata Database Machine основана на рекомендациях Oracle о том, что программное обеспечение OEM, поддерживающее Oracle Linux и Oracle RAC, совместимо с Oracle Exadata.
• На уровне подключаемых баз данных поддерживается новая опция, начинающаяся с Oracle 12c, называемая Multitenant Architecture, состоящая из базы данных контейнера, которая может содержать множество подключаемых баз данных.ArcGIS поддерживает те же функции в подключаемых базах данных, что и Oracle 11g R2.

Требования / ограничения базы данных

Поддержка Oracle 19c начинается с версии Pro 2.4.2

Управление версиями веток поддерживается в Oracle 12.1.0.2
и выше.

Должен быть установлен компонент Oracle Text. Компонент «Текст»
установлен по умолчанию в Oracle; Однако,
если вы не выполнили установку по умолчанию, компонент Текст
возможно, не был установлен.

Поддержка исправлений базы данных Oracle

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

Программное обеспечение, необходимое для подключения к СУБД

На вашем клиентском компьютере (например, на том, на котором выполняется ArcGIS Pro или ArcMap) должны быть установлены соответствующие клиентские файлы для используемой СУБД.Эти клиентские файлы доступны у соответствующих поставщиков СУБД, но некоторые из них также доступны на My Esri для удобства. Клиентские файлы СУБД, доступные на My Esri, — это IBM Db2 и Microsoft SQL Server. Клиентские файлы для Dameng, IBM Informix, IBM Netezza, Oracle, SAP HANA и Teradata недоступны на My Esri и должны быть получены от поставщиков СУБД. См. Раздел Клиенты базы данных для получения дополнительной информации.

Примечание:

Клиенты ArcGIS, подключающиеся к Oracle, должны использовать Oracle 11.2.0.4 или новее клиент.

.

Требования к базе данных Oracle для ArcGIS 10.6.x ArcGIS Pro 2.1 и 2.2 — Системные требования

Посетите службу поддержки Esri, чтобы получить общую информацию о политике поддержки среды Esri.

Поддерживаемые версии базы данных

Standard / Standard One / Enterprise Editions:

Oracle 11g R2 (64 бит) 11.2.0.4

Oracle 12c R1 (64 бит) 12.1.0.2

Oracle 12c R2 (64 бит) 12.2. 0,1

Oracle 18c (64 бит) 18.3.0.0.0, 18.4.0.0.0 — поддерживается с 10.6.1 при установке ArcGIS (Desktop, Engine, Server) 10.6.1 Поддержка Oracle 18c Patch

Oracle 19c (64 бит) 19.3.0.0.0 — поддерживается с 10.6.1, если вы устанавливаете ArcGIS (Desktop, Engine, Server) Support for Oracle 19c Patch

Щелкните здесь, чтобы получить информацию о поддерживаемых исправлениях базы данных Oracle

Поддерживаемые операционные системы

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

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

Дополнительные требования к библиотеке форм ST_Geometry

Esri поддерживает следующие четыре операционные системы, когда вы используете библиотеку форм ST_Geometry и настраиваете внешнюю процедуру Oracle (extproc). В списке указаны минимальные версии операционной системы, если минимальная версия, поддерживаемая Esri, отличается от поддерживаемой базами данных Oracle.

• IBM AIX (64 бит) — для Oracle 11.2.0.4 минимально поддерживаемый
  версия — IBM AIX 6.1.0.0.
• Linux (64 бит) — для Oracle 11.2.0.4 минимально поддерживаемый
  версия — Red Hat Enterprise Linux AS / ES 5 — обновление 11.
• Solaris (64 бит) — для Oracle 11.2.0.4 минимально поддерживаемый
  версия — Solaris 10 SPARC.
• Windows (64 бит)

В Windows вам понадобится последняя версия Visual
Studio VC ++ 2017 установлен на машине базы данных Oracle.См. Https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads
Чтобы получить больше информации.

• Поддержка Oracle Linux основана на документации Oracle о том, что Oracle Linux совместим — как исходный, так и двоичный — с Red Hat Enterprise Linux. См. FAQ по Oracle Linux http://www.oracle.com/us/technologies/027617.pdf.
• Поддержка Oracle Exadata Database Machine основана на рекомендациях Oracle о том, что OEM-программное обеспечение, поддерживающее Oracle Linux и Oracle RAC, совместимо с Oracle Exadata.
• Новая опция Oracle 12c, называемая Multitenant Architecture, состоящая из базы данных контейнера, которая может содержать множество подключаемых баз данных, поддерживается на уровне подключаемых баз данных. ArcGIS поддерживает те же функции в подключаемых базах данных, что и Oracle 11g R2.

Требования / ограничения базы данных

Управление версиями веток поддерживается в Oracle 12.1.0.2
и выше.

Должен быть установлен компонент Oracle Text. Компонент «Текст»
установлен по умолчанию в Oracle; Однако,
если вы не выполнили установку по умолчанию, компонент Текст
возможно, не был установлен.

Поддержка исправлений базы данных Oracle

Поддерживаются исправления

Oracle.
Сюда входят уровни наборов исправлений Oracle и Oracle Interim (разовые)
Патч в соответствии с обзором набора патчей Oracle Corporation и промежуточным периодом
Документация по патчу.

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

Программное обеспечение, необходимое для подключения к СУБД

На вашем клиентском компьютере (например, на том, на котором запущен ArcMap) должны быть установлены соответствующие клиентские файлы для используемой СУБД. Эти клиентские файлы доступны у соответствующих поставщиков СУБД, но некоторые из них также доступны на My Esri для удобства.Клиентские файлы СУБД, доступные на My Esri, — это IBM Db2 и Microsoft SQL Server. Клиентские файлы для ALTIBASE, Dameng, IBM Informix, IBM Netezza, Oracle, SAP HANA и Teradata недоступны на My Esri и должны быть получены от поставщиков СУБД. См. Раздел Клиенты базы данных для получения дополнительной информации.

Примечание:

Клиенты ArcGIS, подключающиеся к базе данных Oracle 12.2.0.1, должны использовать клиент Oracle 11.2.0.4 или новее.

.