В некоторых СУБД, не совместимых с новым Стандартом языка SQL, отсутствует поддержка одной или более фраз PRIMARY KEY, FOREIGN KEY и DEFAULT. Аналогичным образом, многие типы СУБД не поддерживают понятия доменов. В частности, в среде целевой СУБД типа INGRES 6.4 таблица Property for Rent может быть создана с помощью следующего оператора языка SQL: CREATE TABLE property_for_rent( Pno VARCHAR(5) NOT NULL, Street VARCHAR(25) NOT NULL, Area VARCHAR(15), City VARCHAR(15) NOT NULL, Pcode VARCHAR(B), Type CHAR(l) NOT NULL, Rooms SMALLINT NOT NULL, rent MONEY MOT NULL, ono VARCHAR(5) NOT NULL, sno VARCHAR(5), bno VARCHAR(3) NOT NULL) В данном случае все требования, предъявляемые к допустимости значений ключей, принимаемым по умолчанию значениям и доменам атрибутов, должны быть реализованы программно в самих приложениях, которые должны разрабатываться с учетом всех этих требований. Исключением из данного правила являются только ограничения для значений первичных ключей, которые могут быть реализованы с помощью организации уникальных индексов, как описывается ниже. Альтернативный вариант — определить структуру хранения этой таблицы в виде двоичного дерева или ISAM-файла (приложение Б).
Что такое архитектура СУБД и БД? — простыми словами ► ПРАКТИЧЕСКОЕ ПРОГРАММИРОВАНИЕ
4.Реализация с использованием уникальных индексов
Индекс представляет собой механизм доступа, ускоряющий выборку-данных из таблицы—он действует подобно помещенному в книгу указателю (приложение Б). Уникальным называют такой индекс, в котором двум различным кортежам таблицы запрещено иметь одинаковое индексируемое значение.
Система проверяет наличие дублей непосредственно при создании индекса (если данные в таблице уже существуют) и впоследствии контролирует каждое добавляемое в таблицу значение. Многие типы реляционных СУБД поддерживают создание индексов. Уникальный индекс может использоваться для организации контроля за нарушением уникальности значений первичных и потенциальных ключей.
Например, приведенный выше ‘SQL-оператор создания таблицы в среде СУБД INGRES не может воспрепятствовать помещению в таблицу двух записей с одним и тем же значением первичного ключа. С целью предотвращения подобных ошибок для атрибута первичного ключа таблицы (Рnо) можно создать уникальный индекс с помощью следующего оператора языка SQL: CREATE UNIQUE INDEX property_no_index ON property_for_rent(pno); Аналогичным образом можно создать составной индекс для первичного ключа таблицы Viewing, состоящего из атрибутов (Rno, Pno). Вот как выглядит соответствующий SQL-оператор: CREATE UNIQUE INDEX viewing_index ON viewing(rno, pno); Если выбранная целевая СУБД не поддерживает определения первичных и альтернативных ключей, то их следует заменить соответствующими уникальными индексами (если это возможно).
Документирование проекта таблиц базы данных
Подготовленный проект набора таблиц базы данных должен быть тщательно описан в сопроводительной документации. Дополнительно следует указать причины выбора того или иного варианта из всех возможных.
Что такое базы данных? ДЛЯ НОВИЧКОВ / Про IT / Geekbrains
Этап 4.2. Реализация бизнес-правил предприятия в среде целевой субд Цель Реализация бизнес-правил в среде целевой субд.
Обновление информации в таблицах может быть ограничено бизнес-правилами, регулирующими ручное выполнение тех операций, которые связаны с проведением данных обновлений. Способ реализации этих бизнес-правил опять-таки будет зависеть от типа выбранной целевой СУБД, поскольку одни системы для реализации требований организации предлагают больше возможностей, а другие — меньше.
Как и в случае предыдущего этапа, если целевая СУБД поддерживает стандарт языка SQL2, то реализовать определенные типы требований будет совсем просто. Например, в компании DreamHome существует правило, согласно которому каждый работник может одновременно заниматься не более чем десятью сдаваемыми в аренду объектами.
Это ограничение можно включить в SQL-оператор создания таблицы Ргорterty_f or_Rent с помощью следующего предложения: CONSTRAINT staff_not_handling_too_much CHECK (NOT EXIST (SELECT sno FROM property_for_rent GROUP BY sno HAVING COUNT(*)>10)) Альтернативным методом реализации бизнес-правил является использование триггеров. Для реализации приведенного выше примера ограничения в некоторых типах целевых СУБД может быть использован следующий триггер: CREATE TRIGGER staff_not_handling_too_much ON property_for_rent FOR INSERT, UPDATE AS IF ((SELECT COUNT(*) FROM property_for_rent p, WHERE p.
sno = INSERTED.sno) > 10) BEGIN PRINT «Данный работник уже отвечает за 10 объектов» ROLLBACK TRANSACTION END В результате создается триггер, который будет запускаться при каждой попытке вставки новой записи в таблицу Property for Rent, а также при каждой попытке обновления любой записи, уже существующей в этой таблице.
В триггере выполняется проверка количества объектов, за которые отвечает данный сотрудник фирмы. Если это количество уже равно десяти, выводится соответствующее сообщение и выполнение транзакции отменяется. В некоторых системах отсутствует поддержка реализации некоторых или всех типов бизнес-правил. В этом случае соответствующие действия должны быть реализованы непосредственно в приложениях. Например, существует очень мало (если они вообще есть) реляционных СУБД, которые позволяют реализовать ограничения по времени — допустим, такое: «В 17.30 последнего рабочего дня каждого года выполняется архивирование всех строк, относящихся к объектам, проданным в течение этого года, после чего данные записи удаляются».
Источник: studfile.net
Этап 4.2. Реализация бизнес-правил предприятия в среде целевой СУБД
Индекс представляет собой механизм доступа, ускоряющий выборку-данных из таблицы—он действует подобно помещенному в книгу указателю (приложение Б). Уникальным называют такой индекс, в котором двум различным кортежам таблицы запрещено иметь одинаковое индексируемое значение.
Система проверяет наличие дублей непосредственно при создании индекса (если данные в таблице уже существуют) и впоследствии контролирует каждое добавляемое в таблицу значение. Многие типы реляционных СУБД поддерживают создание индексов. Уникальный индекс может использоваться для организации контроля за нарушением уникальности значений первичных и потенциальных ключей. Например, приведенный выше ‘SQL-оператор создания таблицы в среде СУБД INGRES не может воспрепятствовать помещению в таблицу двух записей с одним и тем же значением первичного ключа. С целью предотвращения подобных ошибок для атрибута первичного ключа таблицы (Рnо) можно создать уникальный индекс с помощью следующего оператора языка SQL:
CREATE UNIQUE INDEX property_no_index ON property_for_rent(pno);
Аналогичным образом можно создать составной индекс для первичного ключа таблицы Viewing, состоящего из атрибутов (Rno, Pno). Вот как выглядит соответствующий SQL-оператор:
CREATE UNIQUE INDEX viewing_index ON viewing(rno, pno);
Если выбранная целевая СУБД не поддерживает определения первичных и альтернативных ключей, то их следует заменить соответствующими уникальными индексами (если это возможно).
Документирование проекта таблиц базы данных
Подготовленный проект набора таблиц базы данных должен быть тщательно описан в сопроводительной документации. Дополнительно следует указать причины выбора того или иного варианта из всех возможных.
Цель Реализация бизнес-правил в среде целевой СУБД.
Обновление информации в таблицах может быть ограничено бизнес-правилами, регулирующими ручное выполнение тех операций, которые связаны с проведением данных обновлений. Способ реализации этих бизнес-правил опять-таки будет зависеть от типа выбранной целевой СУБД, поскольку одни системы для реализации требований организации предлагают больше возможностей, а другие — меньше. Как и в случае предыдущего этапа, если целевая СУБД поддерживает стандарт языка SQL2, то реализовать определенные типы требований будет совсем просто. Например, в компании DreamHome существует правило, согласно которому каждый работник может одновременно заниматься не более чем десятью сдаваемыми в аренду объектами. Это ограничение можно включить в SQL-оператор создания таблицы Ргорterty_f or_Rent с помощью следующего предложения:
CONSTRAINT staff_not_handling_too_much
Источник: studopedia.su
Реализация бизнес-правил и анализ транзакций.
Реализацию бизнес-правил (сумма длин переходных кривых не должна быть более длины всей кривой) можно включить в SQL-операторы создания таблиц (CREATE TABLE опция CHECK для полей или таблицы в целом) или в триггеры (CREATE TRIGGER).
После реализации бизнес-правил необходимо проверить выполнимость и эффективность (время отклика, скорость выборки, объем задействованных данных) выполнения всех транзакций.
Разработка механизмов защиты.
Ввиду того, что работают с системой, как правило, несколько пользователей, необходимо продумать механизмы защиты данных от несанкционированного просмотра и модификации. В частности, с системой определения скоростей планируется работа разных пользователей (см. рис.
6.23 внешние сущности на контекстной DFD): инженера службы пути; начальника службы пути, представителей других служб дороги и Департамента пути и сооружений ОАО «РЖД». Каждый из них должен быть наделен соответствующими полномочиями. Так, например, инженер службы пути «головой отвечает» за достоверность исходных данных и результаты расчетов. В связи с этим он должен быть наделен самыми широкими полномочиями. Другие пользователи должны иметь возможность только просмотра результатов расчета и формирования ведомостей.
Ниже рассматриваются два наиболее популярных способа обеспечения защиты данных.
Разработка пользовательских представлений (видов).
Представление пользователя включает в себя данные, необходимые конкретному пользователю для принятия решений или выполнения некоторого задания.
Представление в БД – динамический результат одной или более операций, выполненных над таблицами БД с целью получения новой сводной таблицы. Представление является виртуальной таблицей, которая реально в БД не существует, но создается по запросу (SELECT) определенного пользователя в результате выполнения этого запроса.
В БД представления создаются для упрощения запросов и для организации защиты. Например, с помощью представления можно ограничить доступ к отдельным атрибутам или записям некоторых типов пользователей.
Определение прав доступа (привилегий).
В СУБД, поддерживающих SQL, возможно выполнение запросов от имени определенного пользователя, которое задается администратором БД. Каждый пользователь обладает строго определенным набором прав (привилегий) в отношении конкретной таблицы или представления. Наделение правами выполняется с помощью оператора GRANT, отмена – REVOKE. Операции, на которые можно назначить права: SELECT, INSERT, DELETE и UPDATE. Кроме того, возможно задание передачи прав от одного пользователя к другому.
Организация мониторинга и настройка функционирования системы.
Мониторинг функционирования и достигнутого уровня производительности системы необходим с целью устранения ошибочных проектных решений или изменения требований к системе.
Первоначальный физический проект БД не следует понимать как нечто статическое. Он, скорее, является промежуточным звеном, предназначенным для оценки достигнутого уровня производительности системы. Большинство коммерческих СУБД предоставляет в распоряжение администратора БД набор утилит, предназначенных для наблюдения за функционированием системы и ее настройки.
На практике настройку БД никогда нельзя считать завершенной. На протяжении всего жизненного цикла системы необходимо постоянно вести наблюдение за уровнем ее производительности, что позволит своевременно реагировать на изменения, происходящие в окружающей среде. Внесение в БД изменений, предназначенных для повышения производительности одного из приложений, может отрицательно отразиться на работе другого приложения, возможно, более важного. Таким образом, внесение любых изменений в БД должно проводиться обдумано и осторожно с обязательным их тестированием.
Пример построения физической модели
На рис. 7.20 приведен блок «Информация об участках дороги» физической информационной модели.
Рис. 7.20. Блок «Информация об участках дороги» физической информационной модели
Для ее построения использовался ERwin 4.0. В качестве целевой СУБД выбрана IBM DB2, хотя ERwin позволяет на основе логической модели перейти к физической для более чем 20 самых распространенных серверных (ORACLE, DB2, Informix, MS SQL Server и т.д.) и «настольных» (FoxPro, Access, Paradox и т. д.) СУБД. Данная модель разработана с учетом принятого в DB2 синтаксиса, а также в отличие от логической модели содержит необходимые служебные таблицы.
Вопросы для самопроверки
Дата добавления: 2019-02-22 ; просмотров: 190 ; Мы поможем в написании вашей работы!
Поделиться с друзьями:
Источник: studopedia.net
