Что такое бизнес правила предметной области

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

При разработке базы данных принято выделять несколько уров­ней моделирования, которые служат переходом непосредственно от предметной области к реализации БД на конкретной СУБД:

· общая модель предметной области;

· логическая модель данных;

· физическая модель данных;

· база данных и приложения.

ПРЕДМЕТНАЯ ОБЛАСТЬ

Представляет часть реального мира, данные из которого необ­ходимо отобразить в БД. Так, в качестве предметной области можно выбрать работу отдела кадров какого-либо предприятия, учет успеваемости студентов вуза и т.д. Предметная область очень многогранна и включает в себя массу понятий и данных, как необходимых для построения БД, так и несущественных или даже абсолютно бесполезных. Например, если в качестве пред­метной области выбрать учет успеваемости студентов, то понятия «личная карточка» и «экзаменационная оценка» являются важ­ными, а «материальная помощь» – менее существенным понятием. Следовательно, важность данных очень зависит от выбора предметной области и стоящих перед разработчиком задач.

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

ОБЩАЯ МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ

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

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

ЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ

Описывает взаимосвязи между понятиями предметной облас­ти и налагаемые при этом ограничения.

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

Естественно, кроме самих взаимосвязей, между понятиями могут присутствовать и некоторые ограничения на данные, кото­рые в них циркулируют. Например, оценкой может являться только целое число от 2 до 5.

ФИЗИЧЕСКАЯ МОДЕЛЬ ДАННЫХ

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

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

БАЗА ДАННЫХ И ПРИЛОЖЕНИЯ

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

Access и базы данных

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

Логическая архитектура базы данных

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

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

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

Как и с картотекой, с БД проводят ряд операций над содер­жащейся в ней информацией, например:

■ добавление новой информации;

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

■ управление данными в БД – хранение данных и управление служебной информацией, обеспечивающей работу СУБД;

■ управление памятью компьютера – использование буфериза­ции данных 6 оперативной памяти компьютера;

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

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

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

■ внутренний уровень – описывает, каким образом размещаются данные на устройствах хранения информации. Он, как прави­ло, недоступен пользователям БД для выполнения просмотра и модификации;

■ внешний уровень – задает способ представления данных непо­средственно для пользователей. На этом уровне имеется воз­можность манипуляции данными в СУБД с помощью языка;

■ концептуальный уровень – является как бы переходным уров­нем от внутреннего к внешнему и представляет собой обоб­щенное представление данных в базе.

Пример

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

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

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

При оформлении отчета используется текстовый редактор Microsoft Word 97-2003. Рисунки лучше всего делать во внешних (по отношению к Microsoft Word) графических редакторах и вставить в текст отчета в виде графических файлов.

этап 1. описание предметной области

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

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

– уровень руководства (верхний уровень схемы);

– уровень подразделений предприятия (средний уровень);

– нижний уровень, на котором детализируется структура подразделений предприятия (перечень должностей в подразделении, численный состав сотрудников каждой должности).

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

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

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

Отдел бухгалтерии осуществляет бухгалтерский и кадровый учет. За чистотой на складе и в торговом зале следит уборщик. Директор руководит всей работой в магазине (рис. 1.1).

Рис. 1.1 — Организационная схема книжного магазина

ТОП 5 статей:

Экономическая сущность инвестиций — Экономическая сущность инвестиций – долгосрочные вложения экономических ресурсов сроком более 1 года для получения прибыли путем.
Тема: Федеральный закон от 26.07.2006 N 135-ФЗ — На основании изучения ФЗ № 135, дайте максимально короткое определение следующих понятий с указанием статей и пунктов закона.
Сущность, функции и виды управления в телекоммуникациях — Цели достигаются с помощью различных принципов, функций и методов социально-экономического менеджмента.
Схема построения базисных индексов — Индекс (лат. INDEX – указатель, показатель) — относительная величина, показывающая, во сколько раз уровень изучаемого явления.
Тема 11. Международное космическое право — Правовой режим космического пространства и небесных тел. Принципы деятельности государств по исследованию.

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

Принципы построения баз данных. Жизненный цикл баз данных.

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

— удовлетворять требованиям заказчика и содержать све­дения только о

тех объектах, которые интересуют заказ­чика;

— обладать приемлемым быстродействием, то есть пользова­тель

должен получать необходимые ему сведения за корот­кое время;

— иметь возможность последующего расширения без сущест­венной

переделки, как самой базы данных, так и средств управления ею;

— не зависеть (или мало зависеть) от количества помещаемых в нее

— легко перестраиваться при изменении программной и аппа­ратной

— содержать только достоверные данные. Достоверность дан­ных

должна обеспечиваться как при вводе новых данных, так и при редактировании уже имеющихся данных;

– доступ к данным должны иметь определенные лица.

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

Рассмотрим некоторые этапы жизненного цикла БД.

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

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

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

— формулирование потребностей в новой АИС (определение всех недостатков существующих на рынке программного обеспечения подобных АИС, их высокая стоимость, высокая сложность их сопровождения и т.п.);

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

2 Определение требований к системе. Это этап определения диапазона действия и границ разрабатываемой БД, состава её пользователей, областей применения.

— анализ и выбор направления совершенствования объекта управления в рамках предприятия;

— установление границ исследуемой области;

— связь разрабатываемой системы с существующими на предприятии АИС;

— выбор программно—технических средств;

— определение ограничения ресурсов на разработку;

— определение состава возможных будущих пользователей;

— определение направлений развития.

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

— посредством опроса специалистов предприятия в наиболее важных областях его деятельности;

— с помощью наблюдения за деятельностью предприятия;

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

— за счет использования опыта проектирования других подобных систем;

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

На этапе сбора и анализа требований пользователей полезно ответить на следующие вопросы:

а) Что лежит в основе деятельности данного предприятия. Выявляются наиболее важные компоненты, подлежащие автоматизации. Например: подсистема «Управление персоналом» – компоненты: предприятие, отделы, организационно—кадровая структура, личная карта сотрудника, приказ; задача «Почта» – компоненты: отправитель, получатель, почтовое отделение, главпочта; задача «Занятость населения» – компоненты: отдел по трудоустройству, предприятия, учебные заведения, начисление пособий; задача «Учет кассовых операций» – компоненты: касса, бухгалтерия.

б) Как это делается? Определяется список основных процессов, происходящих на данном предприятии, в частности над компонентами. Например, задача «Почта» – обеспечивается ввод, хранение и обработка данных об отправителе, получателе и почтовом отделении. Автоматически рассчитывается сумма оплаты почтовых услуг и выдается квитанция об оплате. Каждый день составляются и выдаются на печать отчеты о принятых и выданных почтовых отправлениях; задача «Занятость населения» – сбор, накопление, обработка и передача данных о безработных, регистрация вакантных рабочих мест, заполнение карточек персонального учета, ведение истории по безработице, выдача рекомендательных писем; задача «Учет кассовых операций» – ведение журнала регистрации кассовых операций, оформление приходных и расходных, кассовых ордеров и т.п.

в) Где происходят данные процессы? Территориально определяется положение компонентов, решается вопрос оптимального распределения данных (локальная, сетевая БД, БД уровня предприятия, распределенные БД).

г) Кто выполняет эти процессы? Рассматривается организационная структура предприятия – подчинение и зависимость подразделений.

д) Когда выполняется то или иное действие? Проясняется периодичность времени осуществляемых процессов, последовательность выполнения.

е) Почему эти действия выполняются? Определяется мотивация деятельности предприятия. Например: достижение наилучших соотношений «затраты – удобства» для клиентов; обеспечение успешной деятельности персонала; получение приемлемой прибыли; повышение доходов при автоматической обработке данных; получение более эффективного управления.

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

— организационная структура предприятия;

— описание существующих на предприятии информационных потоков, выделение автоматизируемых;

— описание структуры входных и выходных документов;

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

— формализованное описание предметной области – классы объектов (сущности) и связи между ними;

— правила (бизнес – правила, семантические утверждения), ограничивающие предметную область;

— требования к программному обеспечению АИС;

— требования к техническому обеспечению АИС;

— сроки ввода в эксплуатацию АИС.

4 Этап проектирования (моделирования) БД. Это процесс создания проекта БД, предназначенной для поддержки функционирования АИС. Основные действия, производимые на этапе проектирования, это отображение словесного и естественного описания предметной области в схему внутренней модели БД.

Основными целями проектирования БД являются:

— представление данных и связей между ними, необходимых для всех областей применения БД и любых существующих групп пользователей;

— создание модели данных, способной поддерживать выполнение требуемой обработки данных;

— разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы – например, ко времени реакции системы.

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

— максимальное время, отпущенное на проект;

— максимальное количество денег, которое может быть потрачено;

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

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

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

7 Создание БД. Этап физической реализации БД в среде выбранной СУБД. Включает в себя следующее:

— компиляцию команд ЯОД, описывающих БД и структуры объектов БД — создание пустой схемы БД;

— реализацию прикладных программ с помощью языков программирования (многие СУБД имеют встроенный язык);

— реализацию элементов прикладных программ на языке манипулирования данными (ЯМД) СУБД;

— разработку экранных форм для ввода—вывода информации, отчетов;

— реализацию мероприятий по защите данных, как правило, средствами ЯОД и ЯМД СУБД.

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

9 Тестирование БД. Тестирование – процесс выполнения функций, объявленных в АИС, с целью выявления ошибок. Продумывается стратегия теста с использованием реальных данных. Если тестирование проведено успешно, оно обязательно вскроет ошибки в прикладных программах и, возможно, в структурах данных.

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

По завершении этого этапа БД готова к эксплуатации.

10 Эксплуатация и сопровождение. На данном этапе проводится наблюдение за системой и поддержка её нормального функционирования. При этом выполняют следующие виды работ:

— контроль производительности системы. Если она падает, возможна дополнительная настройка или реорганизация БД (денормализация), оптимизация SQL запросов, создание дополнительных объектов БД (индексов);

— сопровождение и модернизация, в случае необходимости, элементов прикладных программ на языке манипулирования данными (ЯМД) СУБД;

— администрирование БД: проверка эффективности системы блокировок в параллельных процессах; осуществление мониторинга работы системы; создание резервных копий БД и т.п.

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

Источник: infopedia.su

Лекция 1. Введение в проектирование баз данных

**1-ый учебный вопрос: Основные определения курса.** *Проектирование баз данных* — процесс создания схемы базы данных и определения необходимых ограничений целостности. На самом деле, в нашем курсе мы пойдем несколько дальше и расширим данное выше определение до следующего вида: *Проектирование баз данных* — процесс создания схемы базы данных и определения необходимых ограничений целостности для реляционной модели данных, процесс создание схемы базы данных для хранилища данных и создание nosql моделей данных.

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

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

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

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

В качестве одной из таких моделей может выступать модель “сущность-связь” (ER-модель). Ниже, дадим основные определения элементов концептуальной модели данных: *Сущность БД* – элемент базы данных, представляющий собой объект, который существует независимо от других, за которым хотел бы осуществлять наблюдение владелец базы данных.

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

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

В противном случае сущность принадлежит к необязательному классу принадлежности. *Имя связи* – любое осмысленное название связи, выраженное в глагольном наклонении. Словарь данных концептуальной модели, связи — центральное хранилище информации, содержащее в себе “тройки”: “описание связи – тип связи – класс принадлежности сущностей, участвующий в связи”. *ER — модель* – наиболее часто применимая в логическом моделировании модель.

ER — модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В настоящий момент времени можно выделить две ключевых нотации для изображения графических диаграмм ER – модели: нотация Питера Чена и нотация Crow’s Foot. *Нотация Питера Чена* — множества сущностей изображаются в виде прямоугольников, множества отношений изображаются в виде ромбов.

Если сущность участвует в отношении, они связаны линией. Если отношение не является обязательным, то линия пунктирная, рис. 1.  *Нотация Crow’s Foot.* Согласно данной нотации, сущность изображается в виде прямоугольника, содержащего её имя, выражаемое существительным.

Связь изображается линией, которая связывает две сущности. Тип связи указывается графически, множественность связи изображается в виде “вилки” на конце связи. Класс принадлежности сущности так же изображается графически — необязательность сущности помечается кружком на конце связи.

Именование обычно выражается одним глаголом в изъявительном наклонении настоящего времени: “имеет”, “принадлежит” и т. д.; или глаголом с поясняющими словами: “включает в себя”, и т.п. Наименование может быть одно для всей связи или два для каждого из концов связи. Во втором случае, название левого конца связи указывается над линией связи, а правого – под линией.

Каждое из названий располагаются рядом с сущностью, к которой оно относится, рис. 2.  *Атрибут* – свойство сущности.

Для каждого атрибута, при концептуальном проектировании определяются следующие значения: — имя атрибута, его краткое описание; — тип атрибута, размерность его значений (если это возможно); — значение атрибута “по умолчанию” (если необходимо); *Первичный ключ сущности* – атрибут сущности, позволяющий уникальным образом идентифицировать ее экземпляры. Далее, поэтапно, перечислим все процедуры концептуального проектирования.

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

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

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

5. Определение значений атрибутов и их документирование (если они дискретны). Дискретные атрибуты (построенные на дискретном, то есть – ограниченном множестве значений, которые они могут принимать) должны быть зафиксированы в словаре данных в виде конечного дискретного множества. Например, <холодный, теплый, горячий>.

6. Определение первичных ключей сущности и их документирование. Сведения об определенных ключах помещаются в словарь данных. 7. Корректировка эскизов моделей с конечными пользователями БД. Результат представляется ER-моделью с сопровождающей документацией (в первую очередь это – словарь данных).

Модель корректируется до тех пор, пока не будет удовлетворять условиям технического задания и/или требованиям конечного пользователя. Возможно проведение аудита соответствия модели техническому заданию. **3-ий учебный вопрос: Логическое проектирование БД.** *Реляционная модель данных* — это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.

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

3).  *Тип данных.* Понятие типа данных в реляционной модели данных полностью адекватно по¬нятию типа данных в языках программирования. Напомним, что традиционно (нестрогое) определение типа данных состоит из трех основных компонентов: — определение множества значений данного типа; — определение набора операций, применимых к значениям типа; — определение способа внешнего представления значе¬ний типа (литералов).

Обычно в современных реляционных базах данных допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как «деньги»), специальных «темпоральных» данных (дата, время, временной интервал), изображений, звуков. В примере на рис. 3 мы имеем дело с данными трех типов: строки символов, целые числа и “деньги”. Домен.

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

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

По определению степенью или «арностью» схемы отношения является мощность этого множества. Например, степень отношения Сотрудники (рис. 3 равна четырем, то есть оно является 4-арным (кватернарным).

Если все атрибуты одного отношения определены на разных доменах, то, что¬бы не плодить лишних имен, разумно использовать для именования атрибутов имена соответствующих доменов. *Схема БД* — это множество именованных схем отношений. *Кортеж.* Множество упорядоченных пар , которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. Значение должно быть допустимым значением домена, на котором определен данный атрибут. *Отношение* — это множество кортежей, соответствующих одной схеме отношения.

Определение первичного ключа аналогично определению его в концептуальной модели данных. Далее, поэтапно, перечислим все процедуры логического проектирования. 1. Выбор модели данных. Чаще всего выбирается реляционная модель данных. 2. Определение набора отношений.

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

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

Проверяются следующие типы ограничений: обязательные данные (без null), доменные ограничения, целостность сущностей (правильные первичные ключи), ссылочная целостность (правильные внешние ключи), ограничения по бизнес-правилам. 6. Корректировка логической модели данных с конечными пользователями.

Результатом будет окончательный вариант словаря данных и er-модели, готовой к конвертации для реализации в одной из СУБД. **4-ий учебный вопрос: Физическое проектирование БД.** Соотнесем определения, которые мы дали применительно к сущности с терминами, которые используются при построении физической модели (табл. 1).

Таблица 1.  Дадим ряд определений для некоторых элементов физической модели. *Физический тип данных* – тип данных, характеризующий столбец с данными. Эти типы данных могут значительно отличаться друг от друга в зависимости от СУБД (MS SQL Server, IBM DB2, Oracle 12c и т.д.), в которой реализована физическая модель. *Уникальный индекс первичного ключа* – индекс, передающий столбцу в таблице все свойства первичного ключа.

Именно по этому индексу СУБД определит первичный ключ в таблице и установит условие ссылочной целостности. *Хранимая процедура* — объект базы данных, представляющий собой набор SQL-инструкций, который компилируется один раз и хранится на сервере. Хранимые процедуры очень похожи на обыкновенные процедуры языков высокого уровня, у них могут быть входные и выходные параметры и локальные переменные, в них могут производиться числовые вычисления и операции над символьными данными, результаты которых могут присваиваться переменным и параметрам.

Обычная хранимая процедура запускается на исполнение пользователем БД. *Триггер* – хранимая процедура, запускаемая СУБД автоматически, при наступлении определенного в коде хранимой процедуры события. *Внешний ключ* — подмножество столбцов некоторой переменной таблицы R2, значения которых должны совпадать со значениями некоторого первичного ключа некоторой переменной таблицы R1. Таблица R2 в этом случае называется потомком, а таблица R1 – родителем.

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

3. Дальнейшая оптимизация физической модели базы данных. Определяется нагрузка на отдельные элементы базы данных, оценивается пропускная способность и время отклика на запросы в обоих направлениях (на выдачу/на запись), создаются дополнительные индексы, если это требуется. 4. Разработка стратегии обеспечения безопасности информации.

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

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