Экзамен Базы данных Отборное / Темы / Тема 3

4

Информационно-логическое моделирование при разработке. Процесс проектирования данных можно условно разделить на два этапа: логическое моделирование и физическое проектирование. Результатом первого из них является так называемая логическая (или концептуальная) модель данных, выражаемая обычно диаграммой «сущность-связь» или ER (Entity-Relationship) диаграммой, которая представлена в одной из стандартных нотаций, принятых для отображения подобных диаграмм. Результатом второго этапа является готовая база данных либо DDL-скрипт для ее создания. Логическая модель данных описывает факты и объекты, подлежащие регистрации в будущей базе данных. Основными компонентами такой модели являются сущности, их атрибуты и связи между ними. Как правило, физическим аналогом сущности в будущей базе данных является таблица, а физическим аналогом атрибута — поле этой таблицы. С логической точки зрения сущность представляет собой совокупность однотипных объектов или фактов, называемых экземплярами этой сущности. Физическим аналогом экземпляра обычно является запись в таблице базы данных. Как и записи в таблице реляционной СУБД, экземпляры сущности должны быть уникальными, то есть полный набор значений их атрибутов не должен дублироваться. И так же, как и поля в таблице, атрибуты могут быть ключевыми и неключевыми. На этапе логического проектирования для каждого атрибута обычно определяется примерный тип данных (строковый, числовой, BLOB и др.). Конкретизация происходит на этапе физического проектирования, так как различные СУБД поддерживают разные типы данных и ограничения на их длину или точность. Моделирование данных Одной из основных частей информационного обеспечения является информационная база, которая представляет собой совокупность данных, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. Разработка БД выполняется с помощью моделирования данных. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С помощью ERD осуществляется детализация накопителей данных DFD – диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами (отношений).Информацию следует разбивать на логические единицы, которые будут подлежать обработке или значимы для идентификации отдельных экземпляров строк и полей таблицы (Например, следует определять поля «Имя» и «Фамилия», а не общее поле «ФИО», если в работе будет требоваться вводить или выводить значение имени). Условия выборки могут представлять собой сложные логические выражения.(да\нет). Модель предметной области. Модель предметной области. Модель предметной области - это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т.п. Опыт показывает, что текстовый способ представления модели предметной области крайне неэффективен. Гораздо более информативными и полезными при разработке баз данных являются описания предметной области, выполненные при помощи специализированных графических нотаций. Имеется большое количество методик описания предметной области. Из наиболее известных можно назвать методику структурного анализа SADT и основанную на нем IDEF0, диаграммы потоков данных Гейна-Сарсона, методику объектно-ориентированного анализа UML, и др. Модель предметной области описывает скорее процессы, происходящие в предметной области и данные, используемые этими процессами. От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки приложений. Связи между таблицами следует определять в рамках схемы данных с учетом бизнес-правил предметной области, которыми в данном случае являются: По курсу проводится несколько занятий. Имеется несколько учебных групп. Каждый студент учится в одной группе. Сущность-связь. ER диаграмма Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области. Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен Ченом (англ. Peter Pin-Shen Chen)[1], американским профессором компьютерных наук в университете штата Луизиана ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (англ. entity-relationship diagram, ERD).

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

Нотация Питера Чена

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

Crow's Foot

Данная нотация была предложена Гордоном Эверестом (англ. Gordon Everest) под названием Inverted Arrow («перевёрнутая стрелка»), однако сейчас чаще называемая Crow's Foot («воронья лапка») или Fork («вилка»).[4]

Согласно данной нотации, сущность изображается в виде прямоугольника, содержащем её имя, выражаемое существительным.[5] Имя сущности должно быть уникальным в рамках одной модели. При этом, имя сущности — это имя типа, а не конкретного экземпляра данного типа. Экземпляром сущности называется конкретный представитель данной сущности.

Связь изображается линией, которая связывает две сущности, участвующие в отношении. Степень конца связи указывается графически, множественность связи изображается в виде «вилки» на конце связи. Модальность связи так же изображается графически — необязательность связи помечается кружком на конце связи. Именование обычно выражается одним глаголом[5] в изъявительном наклонении настоящего времени: «Имеет», «Принадлежит» и т. д.; или глаголом с поясняющими словами: «Включает в себя», и т.п. Наименование может быть одно для всей связи или два для каждого из концов связи. Во втором случае, название левого конца связи указывается над линией связи, а правого – под линией. Каждое из названий располагаются рядом с сущностью, к которой оно относится.

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

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

Ключевые и неключевые атрибуты. Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений:

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

Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание (п. 1.2) ключом является атрибут Номер_рейса или набор: Пункт_отправления, Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).

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

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

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

NULL-значения NULL означает отсутствие, неизвестность информации. Значение NULL не является значением в полном смысле слова: по определению оно означает отсутствие значения и не принадлежит ни одному типу данных. Поэтому NULL не равно ни логическому значению FALSE, ни пустой строке, ни нулю. При сравнении NULL с любым значением будет получен результат NULL, а не FALSE и не 0. Более того, NULL не равно NULL! Довольно часто программисты избегают null-значений и для нулевых полей в базе выставляют значения по умолчанию типа 0, '' (пустая строка). Во-первых, это неправильно с точки зрения семантики: 0 все-таки означает наличие информации. Во-вторых, использование подобных дефолтных значений может привести к ошибкам.

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

Атрибуты связей. Если некоторое свойство характеризует не объект сам по себе, а его связь с другим объектом (объектами), то это атрибут связи, а не атрибут объекта.

различными.

Тип связи «один-ко-многим» Связь типа «один-ко-многим» является наиболее часто используемым типом связи между таблицами. В такой связи каждой записи в таблице A могут соответствовать несколько записей в таблице B, а запись в таблице B не может иметь более одной соответствующей ей записи в таблице A.

Тип связи «многие-ко-многим» При связи «многие-ко-многим» одной записи в таблице A могут соответствовать несколько записей в таблице B, а одной записи в таблице B несколько записей в таблице A. Такая схема реализуется только с помощью третьей (связующей) таблицы, в которой имеются два индексированных поля, которые являются первичным ключом в таблицах A и B. Например, между таблицами «Студент» и «Лабораторная» имеется отношение «многие-ко-многим», которое определяется путем создания двух связей с отношением «один-ко-многим» для таблицы «СтудентЛабораторная».

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

Тип создаваемой связи зависит от полей, для которых определяется связь.

Связь «один-ко-многим» создается в том случае, когда только одно из полей является ключевым или имеет уникальный индекс (не допускающий дубликатов).

Связь «один-к-одному» создается в том случае, когда оба связываемых поля являются ключевыми или имеют уникальные индексы.

Зависимые и независимые сущности. Дочерняя сущность, уникальность которой зависит от атрибута внешнего ключа, называется зависимой сущностью. В примере на рис.1 сущность СОТРУДНИК является зависимой сущностью потому, что его идентификация зависит от сущности ОТДЕЛ. В обозначениях IDEF1X зависимые сущности представлены в виде закругленных прямоугольников.

Зависимые сущности далее классифицируются на сущности, которые не могут существовать без родительской сущности и сущности, которые не могут быть идентифицированы без использования ключа родителя (сущности, зависящие от идентификации). Сущность СОТРУДНИК принадлежит ко второму типу зависимых сущностей, так как сотрудники могут существовать и без отдела.

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

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

Если таблица связана с несколькими другими таблицами, она может иметь несколько внешних ключей. На рис. 1.2 показана таблица Request с тремя внешними ключами, ссылающимися на таблицы Abonent , Executor и Disrepair.

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

Целостность базы данных (DATABASE INTEGRITY) — соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint).

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

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

Поддержка целостности. Выделяют три группы правил целостности: 1) Целостность по сущностям. 2)Целостность по ссылкам. 3) Целостность, определяемая пользователем.

Ограничения целостности обладают следующими свойствами:

Ограничения целостности навязывают правила на уровне таблицы.

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

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

ORACLE автоматически генерирует имена ограниениям при их создании при помощи добавлению SYS_C уникального числа

Существует следующие типы ограничений:

v NOT NULL Ограничения not null – оно не позволяет указанныму столбцу обладать нулевым значение. При попытке задать этому столбцу нулевое значение будет выходить ошибка ограничения целостности. При этом также следует отметить, что ограничения not null можно лишь определить на уровне столбца.

v UNIQUE Ограничения UNIQUE проверяет столбец или столбцы (зависимости от того как его задали) на уникальность строк. Таким образом два одинаковых значения не могут быть даны в одной таблице на указанном столбце или столбцах При этом проверку на строки со значением NULL оно не проверяет, конечно если дополнительно для этого столбца не задано ограничения NOT NULL

v CHECK Ограничения CHECK позволяет ставить ограничение на значение столбцов. При этом синтаксис eстановление этих ограничений такой же как и синтаксис определения ограничения UNIQUE.Например чтобы все было > 0

v PRIMARY KEY В реальной жизни существют множество уникальных чисел: номер нашей автомашины, уникален номер нашего паспорта и.т.д Также необходимо давать подобную уникальность каждой строки в одной таблице. Для этих целей используется ограничения PRIMARY KEY и подобные столбцы обычно называются ID, ну конечно название столбцев может быть любое. Cам по себе PRIMARY KEY представляет из себя:

PRIMARY KEY = UNIQUE + NOT NULL

Ограничение PRIMARY KEY обладает следующеми свойствами:

• В одной таблице может быть только одно ограничение типа PRIMARY KEY

• Ограничение проверяет строки на уникальность и на то чтобы они не были null

• Оно может быть определенно, как на уровне столбца так и на уровне таблицы

• Для столбца автоматически создается индекс (*)

• Поиск по столбцу с ограничением PRIMARY KEY является быстрым поиском (так как по ним автоматически создается индекс)

v FOREIGN KEY

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

Способ определение на уровне столбцов:

column [CONSTRAINT constraintname] constraint_type,

Способ определения на уровне таблицы:

column, ...

[CONSTRAINT constraint_name] constraint_type

(column, ...),

Поддержка целостности при выполнении insert. Триггер - это сохраняемая процедура специального вида, которая запускается в момент модификации данных в таблице. Триггеры помогают сохранить ссылочную целостность данных пользователя, проверяя их согласованность в логически связанных таблицах. Ссылочная целостность означает, что значения главного ключа (primary key) и значение соответствующего внешнего ключа (foreign key) должны в точности совпадать.

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

Триггер “зажигается” (вызывается) только после окончания оператора модификации данных. После запуска триггера SQL Сервер проверяет условия целостности модифицированных данных по типу, соответствию правилам и ограничениям целостности. Триггер и оператор, который вызвал его запуск, рассматриваются как одна транзакция, в рамках которой триггер может вызвать восстановление исходных данных (rolled back) при появлении ошибки. Другими словами, если в процессе проверки обнаруживается серьезная ошибка, то вся транзакция откатывается назад (rolled back).

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

Ссылочная целостность на внешних ключах

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

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

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

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

Запрет — удаление блокируется и возвращается ошибка.

Каскадное удаление — в одной транзакции производится удаление данной записи и всех записей, ссылающихся на данную. Если на удаляемые записи также есть ссылки и настройки также требуют удаления, то каскадное удаление продолжается дальше. Таким образом, после удаления данной записи в базе не остаётся ни одной записи, прямо или косвенно ссылающейся на неё. Если хотя бы одну из ссылающихся записей удалить не получается (либо для неё настроен запрет, либо происходит какая-либо ещё ошибка), то все удаления запрещаются.

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