Бизнес правила базы данных пример

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

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

1 Анализ предметной области

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

1. репертуар и расписание проката кинотеатра должен кто-то вносить в систему — соответствующую роль назовем «Менеджер»;
2. посетитель и кассир должны иметь возможность просматривать расписание, при этом интересно расписание, начиная с некоторого момента времени (например, текущего времени). Составлять оно может по-разному:

1. расписание показа всех фильмов, упорядоченное по времени;
2. расписание прокатов в отдельных залах кинотеатра;
3. расписание проката определенного фильма.

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

Что такое базы данных? ДЛЯ НОВИЧКОВ / Про IT / Geekbrains

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

Каждая сущность, кроме hall_row содержит поле id, которое идентифицирует объект. У сущности hall_row поле id не нужно, так как в одном и том же зале кинотеатра (id_hall) не могут повторяться номера рядов (number).

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

Проектирование баз данных за 40 минут. Практика

2 Построение концептуальной модели

Выше были отображены основные сущности, но не отображены роли пользователей, хотя их тоже должна хранить система. Они показаны ниже на ER-диаграмме в нотации Чена [1].

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

1. создании всех таблиц базы;
2. добавлении залов и рядов в них;
3. добавлении кассиров и менеджеров.

На диаграмме не отражена роль посетителя, так как:

1. билет не содержит информации о том, кто его купил (посетитель может подарить билет другу);
2. система вообще не хранит информацию о посетителях;
3. покупку билета он осуществляет через общение с кассиром вне системы;
4. никакие данные в базе посетитель самостоятельно изменить не может.

На диаграмме проставлены кратности связей, например, видно, что один менеджер может добавить много (N) прокатов. В этой базе не оказалось связей типа N:M, сложных или рекурсивных связей — такие связи являются препятствиями в проектировании и решаются изменением ее структуры.

Для формирования схемы данных необходимо сначала дополнить ER-диаграмму реквизитами сущностей (уточнить ее) — результат приведен на рисунке.

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

• система не должна позволять продавать несколько билетов на одно и то же место при одном показе фильма. Это значит, что вторичным ключем для Билета должен быть кортеж (id_screening, row, seat). Однако, тогда нет необходимости в id билета — на билеты не ссылается ни одна таблица, это поле может быть удалено. Изначально id был добавлен потому, что обычно на билетах в кинотеатрах печатается номер;
• билет хранит поле id_hall, это было сделано для того, чтобы посетитель кинотеатра мог найти свой кинозал. Однако, билет, выдаваемый пользователю — это не тоже самое, что информация о билетах, хранимая в базе данных. Билет базы данных хранит также поле id_screening, а Показ уже ссылается на id_hall. Таким образом, в базе нет смысла хранить id_hall в таблице билетов.

Исправленная ER-диаграмма приведена ниже:

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

CREATE LOGIN Manager_Name WITH PASSWORD=’Some Passwrd’;

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

3 Физическое проектирование

ER-диаграмма отражает основные таблицы, связи и атрибуты, на ее основе можно построить модель БД. На ER-диаграммы нет стандарта, но есть ряд нотаций (Чена, IDEFIX, Мартина и т.п.) [2], но на модель предметной области не удалось найти ни стандарта, ни нотаций. Однако, в ходе построения такой диаграммы обязательно выделяются ключевые поля (внешние и внутренние), иногда — индексы и типы данных. Схема базы данных, приведенная на рисунке, выполнена с использованием открытого инструмента plantuml [3], при этом:

1. для связей используется нотация Мартина («вороньи лапки»);
2. таблицы изображены прямоугольниками, разделенными на 3 секции:

1. имя таблицы;
2. внутренние ключи (помечаются маркером);
3. остальные поля, при этом обязательные поля помечаются маркером.

3.1 Составление и нормализация реляционных отношений

Схема отношения «Билеты» (tickets):

Значение по умолчанию

Ключ или индекс

первичный ключ (составной)

первичный ключ (составной)

первичный ключ (составной)

Схема отношения «Прокаты» (screening):

Значение по умолчанию

Ключ или индекс

Первичный ключ, уникальный

Внешний ключ к hall

Внешний ключ к film

Схема отношения «Кинозалы» (hall):

Значение по умолчанию

Ключ или индекс

Схема отношения «Ряд кинозала» (hall_row):

Значение по умолчанию

Ключ или индекс

первичный ключ (составной)

первичный ключ (составной)

Схема отношения «Фильмы» (film):

Значение по умолчанию

Ключ или индекс

При выборе типов данных и описании их размеров использовалась документация [4]. Для ряда полей, где известно что значениями будут целые числа в небольшом диапазоне используется тип smallint. Для строковых полей используется varchar, однако мог бы использоваться и тип char, критично это только для поля film.description. Дело в том, что описания фильмов бывают длинными, поэтому при создании таблицы надо указать заранее «достаточный» размер поля, например 2000 символов. Однако, согласно документации, при использовании типа char, под все описания фильмов будет выделено 2000 символов, а при использовании varchar более короткие описания будут потреблять меньше памяти — ровно столько, сколько необходимо.
Разработанная схема БД находится в:

1. первой нормальной форме, так как в качестве доменов выступают только скалярные значения и информация в таблицах не дублируется. Почти во всех таблицах есть идентификатор (id), а в остальных — в качестве первичного ключа выступает кортеж (набор полей);
2. во второй и третьей нормальных формах, так как каждый не ключевой атрибут неприводимо и нетранзитивно зависит от первичного ключа. Для всех таблиц нашей БД это очевидно — количество мест в ряду зависит только от пары (номер зала, номер ряда) и никаким другим образом вывести его из информации в базе нельзя.

Таким образом, схема базы данных находится в нормальной форме Бойса-Кодда [5].

3.2 Инсталляция MS SQL Server и создание пустой базы

Был скачан и проинсталлирован MS SQL Server 2014 [6], так как работа выполнялась на 32х-разрядном компьютере, а более новые версии программы не поддерживают такую архитектуру. При установке была выбрана «Установка нового изолированного экземпляра SQL Server» с параметрами по умолчанию. Как показано на рисунке, при установке задано имя экземпляра «my_project».

В результате, на компьютер была установлена программа SQL Server Management Studio, внутри которой выбирается имя сервера, как показано ниже:

После выбора сервера в обозревателе объектов отобразились компоненты сервера, в том числе вкладка «базы данных». В контекстом меню был выбран пункт добавления базы, в качестве имени указано «my_db», как показано на рисунке:

3.3 Формирование таблиц

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

Ключевые поля добавляются в таблицы с помощью контекстоного меню, выпадающего после клика по полю правой кнопкой. Однако, для таблиц с составными и внешними ключами, например hall_row сделать это через графический интерфейс не получилось. В нем были созданы только заготовки таблиц, для них были сгенерированы скрипты T-SQL и дополнены соответствующими параметрами. Для генерации T-SQL скрипта для таблицы в меню выбирается «создать скрипт для таблицы -> используя DROP и CREATE». Сгенерированные скрипты были поправлены, в результате получено следующее:

USE [my_db] GO DROP TABLE [dbo].[hall_row] GO DROP TABLE [dbo].[tickets] GO DROP TABLE [dbo].[screening] GO DROP TABLE [dbo].[hall] GO DROP TABLE [dbo].[film] GO CREATE TABLE [dbo].[film]( id int IDENTITY(1,1) NOT NULL, name varchar(255) NOT NULL, description varchar(2000) NOT NULL, CONSTRAINT [PK_film] PRIMARY KEY CLUSTERED ( id ASC ) ) GO CREATE TABLE [dbo].[hall]( id int IDENTITY(1,1) NOT NULL, name nvarchar(100) NOT NULL, CONSTRAINT [PK_hall] PRIMARY KEY CLUSTERED ( id ASC ) ) GO CREATE TABLE [dbo].[screening]( id int IDENTITY(1,1) NOT NULL, hall_id int NOT NULL, film_id int NOT NULL, time datetime NOT NULL, FOREIGN KEY (hall_id) REFERENCES hall (id), FOREIGN KEY (film_id) REFERENCES film (id), CONSTRAINT [PK_screening] PRIMARY KEY CLUSTERED ( id ASC ) ) GO CREATE TABLE [dbo].[hall_row]( id_hall int NOT NULL, number smallint NOT NULL, capacity smallint NOT NULL, FOREIGN KEY (id_hall) REFERENCES hall (id), CONSTRAINT [PK_hall_row] PRIMARY KEY CLUSTERED ( id_hall, number ) ) GO CREATE TABLE [dbo].[tickets]( id_screening int NOT NULL, row smallint NOT NULL, seat smallint NOT NULL, cost int NOT NULL, FOREIGN KEY (id_screening) REFERENCES screening (id), CONSTRAINT [PK_ticket] PRIMARY KEY CLUSTERED ( id_screening, row, seat ) ) GO

Измененный скрипт был запущен в MS SQL Management Studio, в результате были обновлены таблицы. Затем, на их основе сгенерирована схема базы данных:

3.4 Наполнение базы

Для наполнения базы был создан такой запрос (приведен фрагмент):

INSERT INTO [dbo].[film] (name, description) VALUES (‘Багратион’, ‘«Багратион» — советский двухсерийный историко-биографический фильм 1985 года о жизни прославленного российского полководца Петра Ивановича Багратиона — героя Отечественной войны 1812 года. Совместное производство «Грузия-фильм» и «Мосфильм». Режиссёры Гиули Чохонелидзе и Караман Мгеладзе. Премьера — декабрь 1985 года. ‘) INSERT INTO [dbo].[hall] (name) VALUES (‘красный зал’) INSERT INTO [dbo].[hall] (name) VALUES (‘желтый зал’) INSERT INTO [dbo].[hall] (name) VALUES (‘синий зал’) INSERT INTO [dbo].[hall_row] (id_hall ,number ,capacity) VALUES (1, 1, 10) INSERT INTO [dbo].[hall_row] (id_hall ,number ,capacity) VALUES (1, 2, 15) INSERT INTO [dbo].[hall_row] (id_hall ,number ,capacity) VALUES (1, 3, 20) INSERT INTO [dbo].[screening] (hall_id ,film_id, time) VALUES (1, 1, ‘20210101 10:35:00 AM’) INSERT INTO [dbo].[screening] (hall_id ,film_id, time) VALUES (1, 1, ‘20210101 00:00:00 AM’) INSERT INTO [dbo].[screening] (hall_id ,film_id, time) VALUES (1, 2, ‘20210101 1:35:00 PM’) INSERT INTO [dbo].[tickets] (id_screening ,row ,seat ,cost) VALUES (1, 2, 3, 150) INSERT INTO [dbo].[tickets] (id_screening ,row ,seat ,cost) VALUES (1, 3, 3, 200) INSERT INTO [dbo].[tickets] (id_screening ,row ,seat ,cost) VALUES (1, 3, 5, 150) % .

Запрос выполняется успешно, а результаты его выполнения проверялись с помощью SELECT-запросов:

3.5 Проектирование наиболее востребованных запросов

Как отмечалось в разделе 1, при продаже билета посетитель кинотеатра устно передает кассиру номер и место. Кассир вводит эти данные в систему, которая не должна позволить продать билеты на несуществующие места. Для этого программа-клиент кассира должна получить вместимость ряда конкретного зала. Чтобы получить количество мест во втором ряду третьего зала надо выполнить запрос:

SELECT capacity FROM hall_row WHERE id_hall = 3 AND number = 2

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

Затем, программа-клиент должна проверить не продано ли это место. Для этого можно выполнить отдельный SELECT, но можно попробовать выполнить INSERT INTO и если место было ранее продано — запрос завершится с ошибкой, ведь на таблицу билетов наложены соответствующие ограничения.

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

SELECT * FROM film, screening WHERE time > ‘20210101 11:00:00 AM’ AND screening.film_id = film.id;

в данном случае в запросе используется две таблицы, которые связываются по идентификатору. Выбираются названия фильмов, показ которых начинается после 11 часов 01.01.2021. Результат выполнения запроса:

Для получения расписания проката в конкретном зале кинотеатра надо добавить в запрос связь с третьей таблицей и ограничения на эту таблицу:

SELECT film.name, hall.id, screening.time FROM film, screening, hall WHERE time > ‘20210101 11:00:00 AM’ AND screening.film_id = film.id AND screening.hall_id = hall.id AND hall.id = 2;

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

Для получения расписания проката конкретного фильма — можно вставить в запрос его идентификатор:

SELECT film.name, hall.name, screening.time FROM film, screening, hall WHERE time > ‘20210101 11:00:00 AM’ AND screening.film_id = film.id AND screening.hall_id = hall.id AND film.id = 2;

Если вдруг нас интересуют фильмы, названия которых соответствует определенному шаблону — можно использовать оператор LIKE . Так, приведенный ниже запрос выбирает все фильмы, прокатываемые с определенного момента, названия которых начинаются с символа ‘Б’ , шаблон ‘%’ задает в T-SQL любое количество любых символов.

SELECT film.name, hall.name, screening.time FROM film, screening, hall WHERE time > ‘20210101 11:00:00 AM’ AND screening.film_id = film.id AND screening.hall_id = hall.id AND film.name LIKE ‘Б%’;

Чтобы вывести расписание прокатов, упорядоченное по залу и дате нужно применить конструкцию ORDER BY :

SELECT film.name, hall.name, screening.time FROM film, screening, hall WHERE time > ‘20210101 11:00:00 AM’ AND screening.film_id = film.id AND screening.hall_id = hall.id ORDER BY hall.name, screening.time;

Список полезной литературы

1. Учимся проектированию Entity Relationship — диаграмм // Хабр URL: https://habr.com/ru/post/440556/ (дата обращения: 02.01.2021).
2. Технологии баз данных. Лекция 3. Модель «Сущность-связь». URL: https://docplayer.ru/27886777-Model-sushchnost-svyaz-tehnologii-baz-dannyh-lekciya-3.html (дата обращения: 02.01.2021).
3. Entity Relationship Diagram. URL: https://plantuml.com/ru/ie-diagram (дата обращения: 03.01.2021).
4. Transact-SQL Reference (Database Engine) // Microsoft Docs URL: https://docs.microsoft.com/ru-ru/sql/t-sql/language-reference?view=sql-server-ver15 (дата обращения: 05.01.2021).
5. Нормализация отношений. Шесть нормальных форм // Хабр URL: https://habr.com/ru/post/254773/ (дата обращения: 05.01.2021).
6. Материалы для скачивания по SQL Server // Microsoft URL: https://www.microsoft.com/ru-ru/sql-server/sql-server-downloads (дата обращения: 05.01.2021).
7. Другой пример проектирования базы данных (MySQL). URL: https://pro-prof.com/forums/topic/db_example

Источник: pro-prof.com

Примеры бизнес-правил (службы Master Data Services)

В этой статье приведены примеры бизнес-правил для Master Data Services. Эти примеры можно найти в примерах моделей, включенных в установку Master Data Services.

Инструкции по развертыванию образцов моделей см. в разделе Установка и настройка служб Master Data Services.

Примеры бизнес-правил

Образец модели Сущность Имя бизнес-правила Описание

Customer	Customer	Персональные условия оплаты	Задает условия оплаты по умолчанию для заказчиков.

В следующем бизнес-правиле, если значение атрибута CustomerType соответствует is equal rule condition, then the defaults to rule action is applied to the PaymentTerms attribute. В противном случае не выполняется никаких действий.

If CustomerType is equal to 2 Then PaymentTerms defaults to CASH Else None

Образец модели Сущность Имя бизнес-правила Описание

Customer	Customer	Условия оплаты для организаций	Определяет условия оплаты по умолчанию для организаций.

В следующем бизнес-правиле, если значение атрибута CustomerType соответствует is equal rule condition, then the defaults to rule action is applied to the PaymentTerms attribute. В противном случае не выполняется никаких действий.

If CustomerType is equal to 1 Then PaymentTerms defaults to 210Net30 Else None

Образец модели Сущность Имя бизнес-правила Описание

Продукт	Продукт	DaysToManufacture	Задает диапазон сроков собственного производства.

В следующем бизнес-правиле, если значение атрибута InHouseManufacture соответствует is equal rule condition, then the must be between rule action is applied to the DaysToManufacture attribute. В противном случае не выполняется никаких действий.

If InHouseManufacture is equal to Y Then DaysToManufacture must be between 1 and 10 Else None

Образец модели Сущность Имя бизнес-правила Описание

Продукт	Продукт	Обязательные поля	Задает обязательные поля для элементов сущности продукта.

В следующем правиле is required validation action is taken for the specified attributes. Значения атрибутов не могут быть Null или пустыми.

If None Then Name is required ProductSubCategory is required Color is required StandardCost is required SafetyStockLevel is required ReorderPoint is required InHouseManufacture is required SellStartDate is required FinishedGoodIndicator is required ProductLine is required Else None

Образец модели Сущность Имя бизнес-правила Описание

Продукт	Продукт	Стандартная стоимость	Устанавливает требование, согласно которому стандартная стоимость должна быть больше 0.

В следующем бизнес-правиле must be greater than rule action is applied to the StandardCost attribute of products.

If None Then StandardCost must be greater than 0 Else None

Образец модели Сущность Имя бизнес-правила Описание

Продукт	Продукт	Стоимость MSRP FG	Указывает, что для готовой продукции розничная цена производителя и цена продавца должны быть больше 0.

В следующем бизнес-правиле, если значение атрибута FinishedGoodIndicator соответствует is equal rule condition, the must be greater than rule action is applied to the MSRP and DealerCost attributes.

If FinishedGoodIndicator is equal to Y Then MSRP must be greater than 0 DealerCost must be greater than 0 Else None

Образец модели Сущность Имя бизнес-правила Описание

Продукт	Продукт	Имя по умолчанию	Задает название продукта по умолчанию на основе значений атрибутов Color и Class. Если значение атрибута Color не равно YLO, а значение атрибута Class не равно NA, название по умолчанию — Yellow NA.

В следующем бизнес-правиле, если значения атрибутов Color и Class не соответствуют условию правила is equal , то defaults to применяется к атрибуту Name.

If (Color is equal to YLO AND Class is equal to NA) is not true Then Name defaults to Yellow NA Else Name defaults to Other

Просмотр примеров бизнес-правил в образцах моделей

1. Перейдите на веб-сайт Master Data Services, настроенный после установки MDS, и щелкните поле Администрирование системы.
   Инструкции по настройке веб-сайта см. в разделе Установка и настройка служб Master Data Services.
2. Щелкните образец модели, содержащий бизнес-правило из приведенных выше таблиц, а затем щелкните Сущности.
3. Выберите сущность, к которой применяется правило, как указано в таблицах выше, а затем щелкните Бизнес-правила.
4. Щелкните имя бизнес-правила, которое нужно просмотреть. В пользовательском интерфейсе отобразятся инструкции If, Then и Else .

Источник: learn.microsoft.com

Доклад «Проектирование баз данных, его этапы и задачи»

Цель этапа концептуального проектирования — создание концептуальной модели данных исходя из представлений пользователей о предметной области.

Скачать:

Предварительный просмотр:

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «РОССИЙСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ПРАВОСУДИЯ»

по дисциплине Информационные технологии в деятельности суда

«Проектирование баз данных, его этапы и задачи»

1. Проектирование базы данных………………………………. 4

2. Бизнес-модель процесса проектирования базы данных: сбор и анализ входных данных . 7

2.1 Бизнес-модель процесса проектирования реляционной базы данных: создание логической модели базы данных . 8

2.2 Бизнес-модель этапа проектирования — создание физической модели реляционной базы данных . 10

2.3 Бизнес-модель этапа проектирования — создание физической модели реляционной базы данных: учет влияния транзакций . 11

СПИСОК ЛИТЕРАТУРЫ. 13

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

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

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

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

• функциональность и адаптируемость;
• производительность обработки транзакций;
• пропускная способность;
• время реакции;
• безопасность.

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

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

1. Проектирование базы данных

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

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

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

Известно, что база данных:

Процесс проектирования базы данных может быть представлен в виде модели бизнес-процессов. Бизнес-модель процесса проектирования позволяет:

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

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

Рис. 3.1. Контекстная диаграмма процесса проектирования базы данных

Как видно из рисунка, на вход процесса проектирования базы данных подаются:

• информационная модель предметной области базы данных: диаграммы «сущность-связь» (ER-диаграммы);
• функциональная модель предметной области базы данных: бизнес-модель процессов, диаграммы потока данных (DF-диаграммы), диаграммы состояний, — диаграммы жизненных циклов сущностей, спецификации на системы (требования), бизнес-правила;
• общесистемные требования и ограничения;
• задачи обратного влияния.

На выходе процесса проектирования базы данных формируются следующие результаты:

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

По требованию может быть разработана и другая документация.

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

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

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

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

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

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

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

2. Бизнес-модель процесса проектирования базы данных: сбор и анализ входных данных

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

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

Такими задачами являются:

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

Систематизация требований заказчика к базе данных проводится с целью их адекватного распределения по этапам проектирования базы данных. Важным результатом систематизации является вывод о достаточности требований и реализуемости базы данных. Заказчик должен точно знать, что он получит и чего не получит в результате создания базы данных! Особенно важно указать, чего он не получит. Анализ требований на реализуемость базы данных в рамках конкретного ИТ-проекта служит основой для принятия решения менеджером проекта о возможности реализации проекта в целом.

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

2.1. Бизнес-модель процесса проектирования реляционной базы данных: создание логической модели базы данных

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

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

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

На рис. 3.4-рис. 3.5 представлены бизнес-модели процессов создания логической модели базы данных, нормализации сущности предметной области и нормализации отношений логической модели базы данных соответственно.

Рис. 3.4. Бизнес-модель процесса создания логической модели базы данных

Рис. 3.5. Бизнес-модель процесса нормализации отношения

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

2.3. Бизнес-модель этапа проектирования — создание физической модели реляционной базы данных

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

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

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

Принять решение о способе поддержки ссылочной целостности в базе данных. Эта задача решается в четыре этапа:

• идентифицировать первичные ключи каждой таблицы;
• построить индексы первичного ключа;
• определить внешние ключи в дочерних таблицах, если необходимо;
• построить команды SQL, которые идентифицируют внешние ключи в дочерних таблицах и правила поддержки ссылочной целостности;

Если необходимо, построить представления внешней схемы базы данных.

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

2.4. Бизнес-модель этапа проектирования — создание физической модели реляционной базы данных: учет влияния транзакций

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

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

На этом этапе проектирования физической модели реляционной базы данных проектировщик базы данных:

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

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

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

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

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

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

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

1. Корнеев В.В., Гараев А.Ф., Васютин С.И., Райх В.В. Базы данных. Интеллектуальная обработка информации – М.: Нолидж, 2000
2. Туманов В.Е. Основы проектирования реляционных баз данных. – БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий — ИНТУИТ.ру, 2007

Источник: nsportal.ru