рьл. Документ Microsoft Office Word (2). 1ый учебный вопрос Основные определения курса

Название	1ый учебный вопрос Основные определения курса
Дата	12.09.2022
Размер	408.93 Kb.
Формат файла
Имя файла	Документ Microsoft Office Word (2).docx
Тип	Документы #672433

1-ый учебный вопрос: Основные определения курса.

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

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

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

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

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

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

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

Ниже, дадим основные определения элементов концептуальной модели данных:

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

Экземпляр сущности – отдельно взятый элемент сущности БД, конкретный представитель сущности.

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

Связь – ассоциация, объединяющая несколько сущностей. Может существовать между несколькими сущностями (наиболее распространенная – между двумя сущностями, бинарная) или же между сущностью и ей самой (рекурсивная).

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

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

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

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

Нотация Crow’s Foot. Согласно данной нотации, сущность изображается в виде прямоугольника, содержащего её имя, выражаемое существительным. Связь изображается линией, которая связывает две сущности. Тип связи указывается графически, множественность связи изображается в виде “вилки” на конце связи. Класс принадлежности сущности так же изображается графически - необязательность сущности помечается кружком на конце связи. Именование обычно выражается одним глаголом в изъявительном наклонении настоящего времени: “имеет”, “принадлежит” и т. д.; или глаголом с поясняющими словами: “включает в себя”, и т.п. Наименование может быть одно для всей связи или два для каждого из концов связи. Во втором случае, название левого конца связи указывается над линией связи, а правого – под линией. Каждое из названий располагаются рядом с сущностью, к которой оно относится, рис. 2.

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

имя атрибута, его краткое описание;
тип атрибута, размерность его значений (если это возможно);
значение атрибута “по умолчанию” (если необходимо);

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

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

Определение сущностей и их документирование. Каждой сущности присваивается имя, которое будет понятно другим пользователям. При этом имя будет точно характеризовать смысл сущности. Имена и описание сущностей заносятся в словарь данных. Для каждой сущности примерно устанавливается ожидаемое количество экземпляров.
Определение связей между сущностями и их документирование. Связям присваиваются логичные и понятные имена в глагольном наклонении. Описания связей с их типом, классом принадлежности сущностей и именами заносится в словарь данных.
Создание ER – модели предметной области. Создается несколько альтернативных макетов модели, называемых эскизами. Из этих вариантов выбирается оптимальный вариант модели хранения данных и оптимальный набор его элементов.
Определение атрибутов и их документирование. Каждому атрибуту присваивается осмысленное имя, понятное пользователю и точно раскрывающее его суть. Информация об атрибутах помещается в словарь данных.
Определение значений атрибутов и их документирование (если они дискретны). Дискретные атрибуты (построенные на дискретном, то есть – ограниченном множестве значений, которые они могут принимать) должны быть зафиксированы в словаре данных в виде конечного дискретного множества. Например, {холодный, теплый, горячий}.
Определение первичных ключей сущности и их документирование. Сведения об определенных ключах помещаются в словарь данных.
Корректировка эскизов моделей с конечными пользователями БД. Результат представляется ER-моделью с сопровождающей документацией (в первую очередь это – словарь данных). Модель корректируется до тех пор, пока не будет удовлетворять условиям технического задания и/или требованиям конечного пользователя. Возможно проведение аудита соответствия модели техническому заданию.

3-ий учебный вопрос: Логическое проектирование БД.

Реляционная модель данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД. Основными понятиями реляционных моделей данных являются тип данных, домен, атрибут, кортеж, первичный ключ и отношение.

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

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

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

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

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

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

Схема БД - это множество именованных схем отношений.

Кортеж. Множество упорядоченных пар <имя_атрибута, значение>, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. Значение должно быть допустимым значением домена, на котором определен данный атрибут.

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

Далее, поэтапно, перечислим все процедуры логического проектирования.

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

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

Таблица 1.

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

Уникальный индекс первичного ключа – индекс, передающий столбцу в таблице все свойства первичного ключа. Именно по этому индексу СУБД определит первичный ключ в таблице и установит условие ссылочной целостности.

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

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

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

Выделим этапы физического проектирования баз данных.

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