- •1. 1. Информационные системы. Классификация информационных систем. Место баз данных в информационных системах.
- •2.Основные этапы проектирования бд. Концептуальное, логическое и физическое проектирование бд.
- •Методология idef1x проектирования бд.
- •3.Модели данных. Реляционная модель данных. Структура данных, операции, ограничения целостности реляционной модели данных.
- •Селекция – используется для построения «горизонтального» подмножества отношения, т.Е. Подмножество кортежей удовлетворяет некоторому предикату (логическое условие)
- •4. Нормализация отношений рбд. Обоснование необходимости нормализации. Нормальные формы отношений. Нормализация через декомпозицию отношений.
- •5.Язык sql. Команды создания базы данных и таблиц
2.Основные этапы проектирования бд. Концептуальное, логическое и физическое проектирование бд.
Имеется 2 подхода к проектированию БД:
1.Классический, основанный на нормализации.
Создается одно или несколько базовых отношений. Они анализируются для определенного уровня нормализации. К ним применяется декомпозиция для приведения в нормализующее состояние.
2.Семантическое проектирование БД, основанное на подробном анализе предметной области.
В реальной жизни эти подходы применяются совместно.
Создание концептуальной модели можно представить в виде нескольких этапов:
Определение типов сущностей
Определение типов связей
Определение атрибутов и связывание их с типами сущностей и связей
Определение доменов атрибутов
Определение атрибутов, являющихся потенциальными и первичными ключами
Создание диаграммы «сущность - связь»
Обсуждение концептуальной модели с конечными пользователями
Логическое проектирование – процесс конструктирования общей информационной модели предприятия независимо от особенностей СУБД и других физических условий.
Логическая модель учитывает выбранную модель данных. Результатом этого этапа должна стать корректная, полная и точная модель.
Логическое проектирование включает в себя следующие этапы:
Определение набора отношений исходя из концептуальной модели БД
Проверка модели с помощью правил нормализации
Проверка модели в отношении модели пользователей
Создание полной атрибутивной диаграммы в рамках технологии IEDFIX
Определение требующейся поддержки целостности
Обсуждение логической модели с конечными пользователями
Физическое проектирование:
Перенос логической модели данных в среду целевой СУБД (Разработка таблиц БД и установка определенной целостности. Определяются имена таблиц, имена атрибутов, определение первичных ключей, выбор доменов. Все ограничения, которые отмечены в логической модели должны быть по возможности учтены при построении таблиц.)
Проектирование физического представления БД
Разработка механизмов защиты
Организация мониторинга и настройка системы
Методология idef1x проектирования бд.
IDEF1X-диаграмма строится из трех основных блоков – сущностей, атрибутов, связей.
Сущность – множество индивидуальных объектов-экземпляров, причем все объекты различны.
Атрибут- свойство объекта, характеризующее его экземпляр.
Связь- функциональная зависимость между сущностями.
Определение сущностей.
Извлечение информации из интервью и выделение сущностей.
Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать свойствами:
а) иметь уникальное имя с одной и той же интерпретацией, причем одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;
б) обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;
в) обладать одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности;
г) обладать любым количеством связей с другими сущностями.
На диаграмме сущность изображается прямоугольником с указанием ее имени и номера слева над прямоугольником(например «Группа/1») и атрибутов.
Идентификация атрибутов.
Атрибуты сущности разделены на атрибуты составляющие первичный ключ и прочие (не входящие в первичный ключ). Каждая сущность должна обладать хотя бы одним возможным ключом.
Возможный ключ – один или несколько атрибутов, чьи значения однозначно определяют каждый экземпляр сущности. При существовании нескольких возможных ключей, один обозначается как первичный ключ - атрибут или набор атрибутов, уникально идентифицирующий экземпляр сущности, остальные как альтернативные –атрибут или группа атрибутов, не совпадающих с первичным ключом и уникально идентифицирующая экземпляр сущности.
Все атрибуты ключа должны удовлетворять свойству однозначной идентификации (правило наименьшего ключа). При определении должен ли наследуемый атрибут быть частью ключа, надо выяснить необходим ли этот атрибут для однозначной идентификации.
Правило полной функциональной зависимости – первичный ключ состоит из множества атрибутов, все неключевые атрибуты должны функционально зависеть от всего первичного ключа.
Правило нетранзитивной зависимости – каждый неключевой атрибут должен функционально зависеть только от ключевых атрибутов.
Ни одна из частей ключа не должна иметь значение NULL.
Если несколько наборов атрибутов могут уникально идентифицировать сущность, то выбор одного из них осуществляется разработчиком базы данных на основании анализа предметной области.
Правила выбора первичного ключа из списка предполагаемых ключей таковы:
а) он должен уникальным образом идентифицировать экземпляр сущности;
б) он не может принимать значение NULL;
в) он не должен изменяться со временем, ибо при изменении ключа меняется и экземпляр сущности;
г) он должен быть как можно более коротким для индексирования данных.
Независимая сущность - каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями.
Зависимая сущность - и однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности. На диаграмме она изображается прямоугольником с закругленными углами.
Экземпляры независимой сущности могут быть уникально идентифицированы без определения ее связей с другими сущностями. Экземпляры зависимой сущности, наоборот, не могут быть идентифицированы без определения ее связей с другими сущностями.
Определение зависимостей между сущностями.
Связь – ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью – потомком, а каждый экземпляр сущности – потомка ассоциирован в точности с одним экземпляром сущности – родителя. Таким образом, экземпляр сущности – потомка может существовать только при существовании сущности – родителя.
Связь изображается линией между сущностями, и ей дается уникальное для данной пары сущностей имя в виде оборота глагола, например, «состоит», «является» и т.д. Имя связи всегда формируется с точки зрения родителя.
Связь – это понятие логического уровня, которому соответствует внешний ключ на физическом уровне.
Связь идентифицирующая - если экземпляр дочерней сущности идентифицируется через ее связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в первичный ключ дочерней сущности. Дочерняя сущность при этом является всегда зависимой. Изображается сплошной линией и заканчивается точкой со стороны дочерней сущности.
Неидентифицирующая связь - экземпляр дочерней сущности идентифицируется иначе, чем через связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в состав неключевых атрибутов дочерней сущности. Такая связь изображается пунктирной линией с точкой у дочерней сущности.
Связи дополняются указанием мощности, определяющей, какое количество экземпляров сущности – потомка может существовать для каждого экземпляра сущности – родителя. Если мощность не задана, то предполагается нуль, один и более экземпляров.
Связь категоризации.
Некоторые сущности определяют целую категорию объектов одного типа.
В IDEF1X диаграммах создается сущность для определения категории и для каждого элемента категории, а затем вводится для них связь категоризации.
Супертип – родительская сущность категоризации. Подтип – дочернии.
СОТРУДНИК может содержать данные о преподавателях и инженерах.Общая часть атрибутов (табельный номер, ФИО, адрес, телефон, дата рождения), включая первичный ключ, помещается в сущность сотрудник, а различная часть помещается в сущность-подтип.
В сущности- супертипе вводится атрибут-дискриминатор (Тип_служащего), позволяющий различать конкретные экземпляры сущности-подтипа.В зависимости от того, все ли возможные сущности-подтипы включены в модель, категорийная связь бывает полной или неполной. Если супертип содержит данные о прочих служащих, то связь полной категоризации.
