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

Содержание

Слайд 2

ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

ТЕМА 2: Проектирование баз данных

1. Инфологическое проектирование;
2. Даталогическое проектирование:
а)

ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ ТЕМА 2: Проектирование баз данных 1. Инфологическое проектирование;
логическое проектирование;
б) физическое проектирование.

Слайд 3

ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

ТЕМА 2: Проектирование баз данных

ЗАДАЧА ИНФОЛОГИЧЕСКОГО ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ

ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ ТЕМА 2: Проектирование баз данных ЗАДАЧА ИНФОЛОГИЧЕСКОГО ПРОЕКТИРОВАНИЯ
– получение смысловых моделей, отражающих информационное содержание конкретной области. На этом этапе выполняется восприятие реальной действительности, изучение и описание предметной области.

ОПРЕДЕЛЯЮТСЯ ГРАНИЦЫ ОБЛАСТИ, ПРОИСХОДИТ АБСТРАГИРОВАНИЕ ОТ НЕСУЩЕСТВЕННЫХ ЧАСТЕЙ

ИЗУЧАЕТСЯ ПРЕДМЕТНАЯ ОБЛАСТЬ, НАКАПЛИВАЮТСЯ ЗНАНИЯ О НЕЙ (ЭТИ ЗНАНИЯ ПРЕДСТАВЛЯЮТСЯ В ВИДЕ МОДЕЛЕЙ: МАТЕМАТИЧЕСКИХ ФОРМУЛ, ДИАГРАММ)

ВЫПОЛНЯЕТСЯ СТРУКТУРИЗАЦИЯ ЗНАНИЙ О ПРЕДМЕТНОЙ ОБЛАСТИ

КОМПОНУЕТСЯ КОНЦЕПТУАЛЬНАЯ ИНФОЛОГИЧЕСКАЯ МОДЕЛЬ, ОСНОВНОЕ ЗНАЧЕНИЕ ПРИ ЭТОМ ИМЕЮТ ПОТРЕБНОСТИ ПОЛЬЗОВАТЕЛЕЙ (ОПИСЫВАЕТСЯ ИНФОРМАЦИЯ, ТРЕБУЕМАЯ КАЖДОМУ КОНКРЕТНОМУ ПОЛЬЗОВАТЕЛЮ, Т.Е. ОПИСЫВАЮТСЯ ЗАПРОСЫ К БД)

ЗАДАЧА ЛОГИЧЕСКОГО ЭТАПА ПРОЕКТИРОВАНИЯ – организация данных, в форму, принятую в выбранной конкретной СУБД.

ЗАДАЧА ФИЗИЧЕСКОГО ЭТАПА ПРОЕКТИРОВАНИЯ – выбор рациональной структуры хранения данных и методов доступа к ним, исходя из арсенала методов и средств, который предоставляется разработчику системой управления базами данных.

Слайд 4

ТЕМА 2: Проектирование баз данных

ER-диаграмма (entity-relationship diagram, диаграмма «сущность-связь») – это графическое

ТЕМА 2: Проектирование баз данных ER-диаграмма (entity-relationship diagram, диаграмма «сущность-связь») – это
представление инфологической модели.

ОСНОВНЫЕ ЭЛЕМЕНТЫ ER-МОДЕЛЕЙ:
1) сущности (объекты);
2) атрибуты сущностей;
3) связи между сущностями.

СУЩНОСТЬ – это класс однотипных объектов, информация о которых должна быть учтена в модели. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов как «Поставщик», «Сотрудник», «Накладная». Каждая сущность в модели изображается в виде прямоугольника с наименованием.

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

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

Атрибут сущности – это именованная характеристика, являющаяся некоторым свойством сущности. Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными). Примерами атрибутов сущности «Сотрудник» могут быть такие атрибуты как «Табельный номер», «Фамилия», «Имя», «Отчество», «Должность», «Зарплата» и т.п. Атрибуты изображаются в пределах прямоугольника, определяющего сущность:

Слайд 5

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

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

ТЕМА 2: Проектирование баз данных

Связь - это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою.
Связи позволяют по одной сущности находить другие сущности, связанные с нею.
Например, связи между сущностями могут выражаться следующими фразами:
«СОТРУДНИК может иметь несколько ДЕТЕЙ»;
«каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ». Графически связь изображается линией, соединяющей две сущности:

Слайд 6

Каждая связь имеет два конца и одно или два наименования. Наименование обычно

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

ТЕМА 2: Проектирование баз данных

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

Слайд 7

КАЖДАЯ СВЯЗЬ МОЖЕТ ИМЕТЬ ОДНУ ИЗ ДВУХ МОДАЛЬНОСТЕЙ СВЯЗИ:

ТЕМА 2: Проектирование

КАЖДАЯ СВЯЗЬ МОЖЕТ ИМЕТЬ ОДНУ ИЗ ДВУХ МОДАЛЬНОСТЕЙ СВЯЗИ: ТЕМА 2: Проектирование
баз данных

Модальность «МОЖЕТ» означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.
Модальность «ДОЛЖЕН» означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности.

БАЗА ДАННЫХ СЧИТАЕТСЯ НОРМАЛИЗОВАННОЙ, ЕСЛИ ЕЕ ТАБЛИЦЫ ПРЕДСТАВЛЕНЫ КАК МИНИМУМ В ТРЕТЬЕЙ НОРМАЛЬНОЙ ФОРМЕ.
Первая нормальная форма 1НФ требует атомарности данных в таблицах, т.е. данные в таблицах должны быть представлены в виде минимально возможных и далее неделимых кусочков информации.
Вторая нормальная форма 2НФ требует, чтобы данные во всех неключевых столбцах полностью зависели от первичного ключа.
Третья нормальная форма, известная также как 3НФ, требует от нас, чтобы структура базы данных Удовлетворяла требованиям 1НФ и 2НФ. Все неключевые столбцы таблицы зависели от первичного ключа, но были независимы друг от друга.

Слайд 8

ПРИВЕДЕНИЕ ТАБЛИЦЫ БД К ПЕРВОЙ НОРМАЛЬНОЙ ФОРМЕ:

ТЕМА 2: Проектирование баз данных

ПРИВЕДЕНИЕ

ПРИВЕДЕНИЕ ТАБЛИЦЫ БД К ПЕРВОЙ НОРМАЛЬНОЙ ФОРМЕ: ТЕМА 2: Проектирование баз данных
ТАБЛИЦЫ БД КО ВТОРОЙ НОРМАЛЬНОЙ ФОРМЕ:

Таблица находится в первой нормальной форме, но не во второй. ЦЕНА МАШИНЫ ЗАВИСИТ ОТ МОДЕЛИ И ФИРМЫ. СКИДКА ЗАВИСИТ ОТ ФИРМЫ, ТО ЕСТЬ ЗАВИСИМОСТЬ ОТ ПЕРВИЧНОГО КЛЮЧА НЕПОЛНАЯ.

в одной ячейке содержится список из 3 элементов т.е. он не является атомарным

Слайд 9

ПРИВЕДЕНИЕ ТАБЛИЦЫ БД К ТРЕТЬЕЙ НОРМАЛЬНОЙ ФОРМЕ:

ТЕМА 2: Проектирование баз данных

В

ПРИВЕДЕНИЕ ТАБЛИЦЫ БД К ТРЕТЬЕЙ НОРМАЛЬНОЙ ФОРМЕ: ТЕМА 2: Проектирование баз данных
отношении атрибут «Модель» является первичным ключом.
Личных телефонов у автомобилей нет, и телефон зависит исключительно от магазина.
Таким образом, в отношении существуют следующие функциональные зависимости:
МОДЕЛЬ → МАГАЗИН
МАГАЗИН → ТЕЛЕФОН
МОДЕЛЬ → ТЕЛЕФОН
Зависимость МОДЕЛЬ → ТЕЛЕФОН является транзитивной, следовательно, отношение не находится в 3НФ.
В результате разделения исходного отношения получаются два отношения, находящиеся в 3НФ:
Имя файла: Проектирование-баз-данных.-Тема-2.pptx
Количество просмотров: 40
Количество скачиваний: 0