1. Теоретические основы проектирования и разработки баз данных

1. Основные принципы проектирования реляционных баз данных

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

2. Этапы физической реализации проектируемой базы данных

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

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

• основные объекты предметной

• атрибуты объектов;

• связи между объектами;

• основные запросы к БД.

2. Существующая организация бизнес-процессов и процессов обработки, данных исследуемого объекта по теме курсового проекта

ФИЗИЧЕСКАЯ МОДЕЛЬ НОТАЦИИ IDEF0

(Integration Definition for Function Modeling)

Функциональная модель предназначена для описания существующих бизнес – процессов на предприятии (так называемая модель AS-IS «как есть») и идеального положения вещей – того, к чему нужно стремиться (модель ТО-ВЕ «как должно быть»). Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы.

Построение модели (Рисунок 1) началось с описания функционирования предприятия в виде контекстной диаграммы. В ходе построения модели получилась схема:

Рисунок 1. Контекстная диаграмма

Блок(Activity Box Toll) его имя «фитнес центр». От блока идут стрелки(Precedence Arrow Tool):

• на входе – «клиенты».

• на выходе – «самостоятельная работа», «тренировка с тренером»

• стрелки управления – «Права потребителей», «положение обязанностей фитнес центра»

• стрелки механизм – «тренер» «администратор»

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

Весь процесс фитнес центра подразделяется на:

• запись клиента в фитнес центр

• изучения пожелания клинта

• запись клиента

• проведение занятия с клиентом

(Приложение А)