Проектирование баз данных

Литература
1 Дейт, К. Введение в системы баз данных / К. Дейт: пер. с англ. – 6-е изд. - СПб.: Издательский дом «Вильямс», 2000. - 848 с.
2 Конноли, Т. Базы данных: проектирование, реализация и сопровождение. Теория и практика: учебное пособие / Т. Конноли, К. Бегг, А. Страчан: пер. с англ. - М.: Издательский дом «Вильямс», 2000. – 1120 с.
3 Мюллер, Р.Дж. Базы данных и UML. Проектирование / Р.Дж. Мюллер: пер. с англ. М.: Лори, 2002. – 419 с.
4 Крёнке, Д. Теория и практика построения баз данных / Д. Крёнке. 8—е изд. – СПб.: Питер, 2003. – 800 с.
5 Ульман, Дж.Д. Введение в системы баз данных / Дж.Д. Ульман, Дж. Уидом: пер. с англ. – М.: Лори, 2000. – 374 с.
6 Энсор, Д. Oracle. Проектирование баз данных / Д. Энсор, Й. Стивенсон: пер. с англ.: — К.: BHV, 1999. – 560 с.
7 Стивенс, Р. Программирование баз данных / Р. Стивенс: пер. с англ.: — М.: Бином—Пресс, 2003. – 384 с.
8 Луни, К. Oracle 9i. Настольная книга администратора / К. Луни, М. Терьо: пер. с англ.: М., Лори, 2004. – 745 с.

ВОПРОСЫ
Архитектура БД.
Модели данных, используемые на различных этапах проектирования БД.
Внешний уровень архитектуры БД.
Концептуальный уровень архитектуры БД.

Трехуровневая архитектура БД
ПП1 – представление 1-го пользователя, ПП к - представление к - того пользователя

Модели данных
Внешняя модель данных (описание предметной области на естественном языке)
Концептуальная модель (диаграмма, схема, рисунок)
Внутренняя модель (язык СУБД)

Модели данных, используемые при проектировании БД

Жизненный цикл БД
Планирование разработки БД
Определение требований к системе
Сбор и анализ требований пользователя
Проектирование
Выбор СУБД
Разработка приложений
Создание БД
Конвертирование и загрузка данных из старой системы
Тестирование БД
Эксплуатация и сопровождение

Метод нисходящего проектирования
Пр Обл – предметная область; ИЛМ – информационно - логическая модель предметной области; ДЛМ – даталогическая модель; НФ – нормальная форма;
ФМ – физическая модель.

Современный метод проектирования
Инфологическое проектирование
Даталогическое проектирование
Физическое проектирование

Проектирование БД
Формирование внешнего уровня БД

Организационная структура предприятия. Информационные потоки

Информационные потоки
1 – штатное расписание подразделения;
2 – заявление о приеме/увольнении;
3 – трудовой договор;
4 – приказ о приеме/увольнении;
5 – отчет о количественном составе контингента сотрудников;
6 – внешний отчет;
7 – отчет об исполнении штатного расписания

Общая диаграмма потоков работ

Детализированная диаграмма потоков работ

Диаграмма потоков данных

Состав функциональной подсистемы
«Управление персоналом»

Функциональная иерархия

Отличия между классом объектов и свойством

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

Формализованное описание предметной области. Классы объектов, свойства.

Правило чтения связи

В любой предметной области нет связей «многие_ко_многим», в каждый момент времени всё определяется однозначно. Появление такой связи в проектной документации показывает, что предметная область не дообследована. Связь М:М может быть «разорвана» каким—либо документом или позицией документа.

Формализованное описание предметной области. Связи между классами объектов
КО – класс объектов; Д.б. – должна быть, М.б. – может быть

Уровни доступа пользователей подсистемы "Управление персоналом"

Проектирование БД
Разработка концептуального уровня БД

Методология Ричарда Баркера
класс объектов,
свойство класса объектов,
уникальные идентификаторы,
опциональность свойств,
мощность (тип),
опциональность и переносимость связей,
уникальность объектов из связей,
супертипы,
подтипы,
арки.

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

четырехугольник, отображающий класс объектов, можно увеличивать до любых размеров, четырехугольники могут быть разных размеров;
опциональность свойств помечается: обязательное свойство – звездочкой (*), необязательное – кружочком (о);
уникальный идентификатор помечается #, если уникальных идентификаторов несколько, тогда каждый помечается номером, указанным в скобках, например, # (1), #(2);
обязательная связь помечается сплошной линией, необязательная – пунктирной;
тип (мощность) связи «один» помечается линией, «много» — «вороньей лапой».

Последовательность нормальных форм
• 1НФ - первая нормальная форма (1NF);
• 2НФ - вторая нормальная форма (2NF);
• 3НФ - третья нормальная форма (3NF);
• НФБК - нормальная форма Бойса-Кодда (BCNF):
• 4НФ - четвертая нормальная форма (4NF);
• 5НФ или НФПС - пятая нормальная форма или нормальная форма проек­ции-соединения (5NF или PJ/NF);
• ДКНФ – доменно-ключевая нормальная форма (Domain/Key Normal Form, DK/NF).

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

Пример рекурсивной связи

Пример иерархии данных

Пример использования шаблона для моделирования иерархии данных.

Разрыв связи М:М

Неправильное моделирование ролей

Правильное моделирование ролей

Примеры моделирования ролей

Пример моделирования ролей

Пример супертипа и подтипов

Пример использования арка

Нормализация на уровне ER—диаграммы

Пример модели предметной области

Даталогическое проектирование

ПК – первичный ключ, ВК – внешний ключ, ФЛ – физическое лицо,
ЮЛ – юридическое лицо, НП – населенный пункт.

Физическое
проектирование

Современные СУБД

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

Техническое описание таблицы «Должность» на ЯОД СУБД Access