Добавил:
больше работ здесь: https://github.com/alisadex Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лабораторные работы (Создание своей СУБД) / ППСУБДиЗ финальная версия документации.docx
Скачиваний:
4
Добавлен:
11.02.2024
Размер:
500.04 Кб
Скачать

Этап 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

Определение типов данных полей

  1. Таблица: Products

    • ProductID: Целочисленный (Primary Key)

    • Name: Строковый

    • Brand: Строковый

    • Type: Строковый

    • Price: Десятичный

    • Description: Текстовый

    • Ingredients: Текстовый

    • Characteristics: Текстовый

  2. Таблица: Customers

    • CustomerID: Целочисленный (Primary Key)

    • Name: Строковый

    • ContactInfo: Текстовый

    • Address: Текстовый

  3. Таблица: ProductDetails

    • ProductID: Целочисленный (Primary Key, Foreign Key)

    • Price: Десятичный

    • Ingredients: Текстовый

    • Characteristics: Текстовый

  1. Таблица: Suppliers

  • SupplierID: Целочисленный (Primary Key)

  • Name: Строковый

  • ContactInfo: Текстовый

  • DeliveryTerms: Текстовый

  1. Таблица: Orders

  • OrderID: Целочисленный (Primary Key)

  • CustomerID: Целочисленный (Foreign Key)

  • ProductID: Целочисленный (Foreign Key)

  • Quantity: Целочисленный

  • Price: Десятичный

  • DeliveryStatus: Строковый

  • PaymentStatus: Строковый

  1. Таблица: OrderDetails

  • OrderID: Целочисленный (Foreign Key)

  • ProductID: Целочисленный (Foreign Key)

  • Quantity: Целочисленный

  • Price: Десятичный

  1. Таблица: Warehouse Inventory

  • ItemID: Целочисленный (Primary Key)

  • ProductID: Целочисленный (Foreign Key)

  • SupplierID: Целочисленный (Foreign Key)

  • Quantity: Целочисленный

  • Location: Строковый

  1. Таблица: Sales and Reports

  • ReportID: Целочисленный (Primary Key)

  • ProductID: Целочисленный (Foreign Key)

  • Date: Дата

  • Revenue: Десятичный

  • SoldProducts: Текстовый

  1. Таблица: Marketing and Promotions

  • PromotionID: Целочисленный (Primary Key)

  • ProductID: Целочисленный (Foreign Key)

  • Name: Строковый

  • Description: Текстовый

  • Cost: Десятичный

  1. Таблица: Employees

  • EmployeeID: Целочисленный (Primary Key)

  • OrderID: Целочисленный (Foreign Key)

  • AdminID: Целочисленный (Foreign Key)

  • Name: Строковый

  • Role: Строковый

  • ContactInfo: Текстовый

  • WorkSchedule: Текстовый

  1. Таблица: AdminData

  • AdminID: Целочисленный (Primary Key)

  • UserName: Строковый

  • Password: Строковый

  • AccessLevel: Строковый

Нормализация

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

Давайте рассмотрим каждую сущность и приведем их к третьей нормальной форме.