- •«Московский технический университет связи и информатики»
- •«Принципы построения систем управления базами данных и знаний»
- •Этап 1. Анализ предметной области
- •Этап 2. Определение бизнес-функции, выделение сущностей и их атрибутов.
- •Этап 3. Определить связи сущностей, составить инфологическую модель данных.
- •Этап 4. Определить поля бд, определить ключевые поля, определить типы данных полей. Нормальные формы. Составить даталогическую модель.
- •1 Таблица: Products
- •2 Таблица: Customers
- •3 Таблица: Suppliers
- •4 Таблица: Orders
- •Даталогическая модель.
- •Этап 4. Выбор субд
- •Этап 5. Создание физической модели в PostgreSql.
- •Этап 6. Запросы к бд
Этап 3. Определить связи сущностей, составить инфологическую модель данных.
Определение типов и видов связей
Определим типы связей между таблицами:
1. Таблица: Orders и Customers
Тип связи: Многие к одному (Many-to-One)
Вид связи: Каждый заказ (Orders) связан с одним клиентом (Customers), но каждый клиент может иметь много заказов.
2. Таблица: Orders и Products
Тип связи: Многие к одному (Many-to-One)
Вид связи: Каждый заказ (Orders) связан с одним продуктом (Products), но каждый продукт может встречаться во многих заказах.
3. Таблица: Warehouse Inventory и Products
Тип связи: Один к одному (One-to-One)
Вид связи: Каждая запись в Warehouse Inventory связана с одним продуктом из Products, и наоборот.
4. Таблица: SalesAndReports и Products
Тип связи: Многие к одному (Many-to-One)
Вид связи: Множество записей в таблице SalesAndReports может быть связано с одним и тем же продуктом из таблицы Products.
5. Таблица: Marketing и Products
Тип связи: Многие к одному (Many-to-One)
Вид связи: Множество записей в таблице MarketingAndPromotions может быть связано с одним и тем же продуктом из таблицы Products.
6. Таблица: Employees и Orders
Тип связи: Многие к одному (Many-to-One)
Вид связи: Множество записей в таблице Orders может быть связано с одним и тем же сотрудником из таблицы Employees.
7. Таблица: AdminData и Employees
Тип связи: Многие к одному (Many-to-One)
Вид связи: Каждый сотрудник (Employees) связан с одним администратором (AdminData), но каждый администратор может быть связан с множеством сотрудников.
8. Таблица: WarehouseInventory и Suppliers
Тип связи: Многие к одному (Many-to-One)
Вид связи: Каждый склад (WarehouseInventory) связан с одним поставщиком (Suppliers), но каждый поставщик может быть связан с множеством складов.
Инфологическая модель
Инфологическая модель данных представляет собой абстракцию структуры данных, не зависящую от конкретных технологий баз данных. Ниже представлена инфологическая модель данных (рис.1).
Рис.1 Инфологическая модель данных
Этап 4. Определить поля бд, определить ключевые поля, определить типы данных полей. Нормальные формы. Составить даталогическую модель.
Выявление ключей
1. Таблица: Products
Primary Key: ProductID
2. Таблица: ProductDetails
Primary Key: ProductID
Foreign Key: ProductID (ссылается на Products)
3. Таблица: Customers
Primary Key: CustomerID
4. Таблица: Suppliers
Primary Key: SupplierID
5. Таблица: Orders
Primary Key: OrderID
Foreign Keys: CustomerID (ссылается на Customers), ProductID (ссылается на Products)
6. Таблица: WarehouseInventory
Primary Key: ItemID
Foreign Key: ProductID (ссылается на Products), SupplierID (ссылается на Suppliers)
7. Таблица: SalesAndReports
Primary Key: ReportID
Foreign Key: ProductID (ссылается на Products)
8. Таблица: Marketing
• Primary Key: MarketingID
• Foreign Key: ProductID (ссылается на Products)
9. Таблица: Employees
• Primary Key: EmployeeID
• Foreign Key: AdminID (ссылается на AdministrativeData), OrderID (ссылается на Orders)
10.Таблица: OrdersDetails
Foreign Key: ProductID (ссылается на Products), OrderID (ссылается на Orders)
11. Таблица: AdministrativeData
• Primary Key: AdminID
Определение типов данных полей
Таблица: Products
ProductID: Целочисленный (Primary Key)
Name: Строковый
Brand: Строковый
Type: Строковый
Price: Десятичный
Description: Текстовый
Ingredients: Текстовый
Characteristics: Текстовый
Таблица: Customers
CustomerID: Целочисленный (Primary Key)
Name: Строковый
ContactInfo: Текстовый
Address: Текстовый
Таблица: ProductDetails
ProductID: Целочисленный (Primary Key, Foreign Key)
Price: Десятичный
Ingredients: Текстовый
Characteristics: Текстовый
Таблица: Suppliers
SupplierID: Целочисленный (Primary Key)
Name: Строковый
ContactInfo: Текстовый
DeliveryTerms: Текстовый
Таблица: Orders
OrderID: Целочисленный (Primary Key)
CustomerID: Целочисленный (Foreign Key)
ProductID: Целочисленный (Foreign Key)
Quantity: Целочисленный
Price: Десятичный
DeliveryStatus: Строковый
PaymentStatus: Строковый
Таблица: OrderDetails
OrderID: Целочисленный (Foreign Key)
ProductID: Целочисленный (Foreign Key)
Quantity: Целочисленный
Price: Десятичный
Таблица: Warehouse Inventory
ItemID: Целочисленный (Primary Key)
ProductID: Целочисленный (Foreign Key)
SupplierID: Целочисленный (Foreign Key)
Quantity: Целочисленный
Location: Строковый
Таблица: Sales and Reports
ReportID: Целочисленный (Primary Key)
ProductID: Целочисленный (Foreign Key)
Date: Дата
Revenue: Десятичный
SoldProducts: Текстовый
Таблица: Marketing and Promotions
PromotionID: Целочисленный (Primary Key)
ProductID: Целочисленный (Foreign Key)
Name: Строковый
Description: Текстовый
Cost: Десятичный
Таблица: Employees
EmployeeID: Целочисленный (Primary Key)
OrderID: Целочисленный (Foreign Key)
AdminID: Целочисленный (Foreign Key)
Name: Строковый
Role: Строковый
ContactInfo: Текстовый
WorkSchedule: Текстовый
Таблица: AdminData
AdminID: Целочисленный (Primary Key)
UserName: Строковый
Password: Строковый
AccessLevel: Строковый
Нормализация
Нормализация базы данных — это процесс организации данных с целью уменьшения избыточности и предотвращения аномалий при обновлении, вставке и удалении данных. То есть устранение зависимостей и структурирование данных.
Давайте рассмотрим каждую сущность и приведем их к третьей нормальной форме.