Similar presentations:
практическая работа 4
1. Практическая работа 4 Логическое проектирование базы данных
2. Логическое проектирование базы данных
Проектирование базы данных обычно проходит три последовательных этапа:2
Этап
Суть
Концептуальное
проектирование
Создание модели предметной области, независимой от СУБД и технической
реализации (выясняются участники процесса, их цели и используемые данные.
Разрабатываются сценарии использования и выявляются ключевые сущности).
Логическое
проектирование
Преобразование концептуальной модели в структуры выбранной модели данных
(например, реляционной) (создаётся модель данных, показывающая, какие таблицы
будут, какие у них поля и связи. Здесь определяются ключи, типы данных и
ограничения (NOT NULL, UNIQUE, FOREIGN KEY). Выполняется нормализация.
Физическое
проектирование
Реализация логической модели в конкретной СУБД с учётом особенностей хранения,
индексов и т.д. (адаптация логической модели под конкретную СУБД (в нашем случае
— PostgreSQL).
3. Логическое проектирование базы данных
Инструменты моделированияДля визуализации структуры часто применяются ER-диаграммы (Entity–Relationship).
Существуют различные инструменты: MySQL Workbench, dbdiagram.io, draw.io, ERwin) и
другие.
Для визуализации будем использовать онлайн редактор диаграмм Draw.io https://app.diagrams.net
3
4. Практическая работа Логическое проектирование базы данных
Этапы:Выбор предметной области (самостоятельно или из списка).
Выбирайте область, которая вам знакома или интересна. Анализ предметной области.
1. Определение сущностей, атрибутов, связей, ключей, типов данных, и ограничений,
нормализация.
2. Графическое изображение ER-модели.
3. Загрузка работы в ЭИОС и защита.
4
5. Практическая работа Логическое проектирование базы данных
Предметная область, примеры:1) Библиотека.
2) Интернет магазин.
3) Поликлиника.
4) Гостиница.
5) Служба доставки еды.
6) Автосервис.
7) Фитнес клуб.
8) Учет кадров.
9) Бронирование билетов (на выбор кино, театр, концерты, авиа, жд. и тд.).
10) Склад.
11) Ветклиника.
12) Служба доставки.
13) Управление парковкой.
14) Учёт недвижимости (аренда, продажа).
15) Ресторан.
5
6. Логическое проектирование базы данных туристического агентства
Цель: Создать логическую модель БД для автоматизации работы туристического агентства.6
7. Логическое проектирование базы данных на примере базы данных туристического агентства
7Сущность
Что описывает
CLIENTS
Клиенты, которые
покупают туры
TOURS
Туры, которые продаёт
агентство
EMPLOYEES
Сотрудники-менеджеры
агентства
BOOKINGS
Заявки (бронирования)
— связывает клиента,
тур и менеджера
8. Логическое проектирование базы данных на примере базы данных туристического агентства
CLIENTS — Клиенты: хранит персональные данныеклиентов агентства.
№
8
Атрибут
Ключ
Ограничения
Описание
1
client_id
PK
NOT NULL
Уникальный идентификатор
клиента, генерируется
автоматически
2
last_name
-
NOT NULL
Фамилия клиента
3
first_name
-
NOT NULL
Имя клиента
4
phone
-
—
Контактный телефон
5
-
—
Электронная почта
6
passport_number
UQ
UNIQUE
Серия и номер паспорта,
уникальны
9. Логическое проектирование базы данных на примере базы данных туристического агентства
TOURS — Туры каталог туров, которые продаёт агентство.9
№
Атрибут
Ключ
Ограничения
Описание
1
tour_id
PK
NOT NULL
Уникальный идентификатор тура
2
name
NOT NULL
Название тура
3
sity
NOT NULL
Город назначения
4
start_date
—
Дата начала тура
5
end_date
CHECK (end_date >=
Дата окончания тура, не раньше
start_date)
начала
6
price
NOT NULL, CHECK (price >=
0)
Стоимость на одного человека
10. Логическое проектирование базы данных на примере базы данных туристического агентства
EMPLOYEES — Сотрудники данные о менеджерах, оформляющих заявки.10
№
Атрибут
Ключ
Ограничения
Описание
1
employee_id
PK
NOT NULL
2
last_name
NOT NULL
Фамилия
3
first_name
NOT NULL
Имя
4
position
—
5
phone
—
Рабочий телефон
6
—
Рабочая почта
Уникальный идентификатор
сотрудника
Должность (менеджер, старший
менеджер и т.п.)
11. Логическое проектирование базы данных на примере базы данных туристического агентства
BOOKINGS — Заявки (бронирования) центральная таблица. Фиксирует факт покупки тура клиентомчерез конкретного менеджера.
11
№
Атрибут
Ключ
Ограничения
1
booking_id
PK
NOT NULL
2
client_id
FK → CLIENTS.client_id
NOT NULL
Кто оформил заявку
3
tour_id
FK → TOURS.tour_id
NOT NULL
Какой тур выбран
4
employee_id
— (может быть NULL)
Какой менеджер оформил
5
booking_date
NOT NULL, DEFAULT CURRENT_DATE
Дата оформления заявки
6
tourists_count
NOT NULL, CHECK (tourists_count > 0)
Количество туристов
7
status
FK →
EMPLOYEES.employee_id
NOT NULL, CHECK (status IN
('new','confirmed','paid','cancelled'))
Описание
Уникальный идентификатор
заявки
Статус заявки
12. Логическое проектирование базы данных на примере базы данных туристического агентства
НормализацияВсе таблицы в 1НФ.
Все PK — односоставные (суррогатные ID), частичных зависимостей быть не может.
Все атрибуты зависят напрямую от PK.
Транзитивных нет.
12