Использование инструмента ERD в pgAdmin 4

Задание:

  1. Используя инструмент ERD в pgAdmin 4, создайте новый проект ERD.
  2. Создайте таблицы, как определено в схеме, указав соответствующие типы данных и первичные ключи.
  3. Установите связи между таблицами, создав внешние ключи, как указано. Используйте инструмент “один-ко-многим” для каждого ограничения внешнего ключа.
  4. Автоматически выровняйте таблицы для лучшей читаемости.
  5. Сгенерируйте SQL DDL скрипт для этой схемы базы данных.
  6. Сохраните ваш проект ERD.
Вариант 1: Система управления библиотекой

Сценарий: Спроектируйте базу данных для небольшой библиотеки, чтобы управлять ее коллекцией книг, авторов, читателей и выдачей книг.

Схема базы данных:

  • Таблицы:
    • Books (Книги):
      • book_id (integer, Primary Key) - Уникальный идентификатор каждой книги.
      • title (character varying) - Название книги.
      • isbn (character varying) - Международный стандартный книжный номер.
      • publication_year (integer) - Год публикации.
      • genre (character varying) - Жанр книги.
    • Authors (Авторы):
      • author_id (integer, Primary Key) - Уникальный идентификатор каждого автора.
      • first_name (character varying) - Имя автора.
      • last_name (character varying) - Фамилия автора.
    • Book_Authors (Книги_Авторы): (Таблица-связка для отношения “многие-ко-многим” между книгами и авторами)
      • book_id (integer, Foreign Key referencing Books(book_id))
      • author_id (integer, Foreign Key referencing Authors(author_id))
      • (Составной первичный ключ: book_id, author_id)
    • Borrowers (Читатели):
      • borrower_id (integer, Primary Key) - Уникальный идентификатор каждого читателя.
      • first_name (character varying) - Имя читателя.
      • last_name (character varying) - Фамилия читателя.
      • address (character varying) - Адрес читателя.
      • phone_number (character varying) - Номер телефона читателя.
    • Loans (Выдачи):
      • loan_id (integer, Primary Key) - Уникальный идентификатор каждой выдачи.
      • book_id (integer, Foreign Key referencing Books(book_id))
      • borrower_id (integer, Foreign Key referencing Borrowers(borrower_id))
      • loan_date (date) - Дата выдачи книги.
      • return_date (date, Nullable) - Дата возврата книги (может быть null, если книга еще не возвращена).
  • Связи:
    • Один-ко-многим между Authors и Book_Authors (Один автор может написать несколько книг).
    • Один-ко-многим между Books и Book_Authors (Одна книга может быть написана несколькими авторами).
    • Один-ко-многим между Books и Loans (Одна книга может быть выдана несколько раз).
    • Один-ко-многим между Borrowers и Loans (Один читатель может взять несколько книг).
Вариант 2: База данных интернет-магазина книг

Сценарий: Спроектируйте базу данных для интернет-магазина книг, чтобы управлять книгами, авторами, покупателями, заказами и издателями.

Схема базы данных:

  • Таблицы:
    • Books (Книги):
      • book_id (integer, Primary Key)
      • title (character varying)
      • isbn (character varying)
      • publication_year (integer)
      • price (numeric)
      • publisher_id (integer, Foreign Key referencing Publishers(publisher_id))
    • Authors (Авторы):
      • author_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
    • Book_Authors (Книги_Авторы): (Таблица-связка)
      • book_id (integer, Foreign Key referencing Books(book_id))
      • author_id (integer, Foreign Key referencing Authors(author_id))
      • (Составной первичный ключ: book_id, author_id)
    • Customers (Покупатели):
      • customer_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • email (character varying)
      • address (character varying)
    • Publishers (Издатели):
      • publisher_id (integer, Primary Key)
      • publisher_name (character varying)
      • publisher_address (character varying)
    • Orders (Заказы):
      • order_id (integer, Primary Key)
      • customer_id (integer, Foreign Key referencing Customers(customer_id))
      • order_date (date)
    • Order_Items (Позиции_заказа): (Таблица-связка для отношения “многие-ко-многим” между заказами и книгами)
      • order_item_id (integer, Primary Key) - Уникальный идентификатор каждой позиции в заказе.
      • order_id (integer, Foreign Key referencing Orders(order_id))
      • book_id (integer, Foreign Key referencing Books(book_id))
      • quantity (integer)
      • price (numeric) - цена книги на момент заказа (может отличаться от текущей цены).
  • Связи:
    • Один-ко-многим между Authors и Book_Authors.
    • Один-ко-многим между Books и Book_Authors.
    • Один-ко-многим между Publishers и Books.
    • Один-ко-многим между Customers и Orders.
    • Один-ко-многим между Orders и Order_Items.
    • Один-ко-многим между Books и Order_Items.
Вариант 3: База данных системы регистрации на курсы университета

Сценарий: Спроектируйте базу данных для университета, чтобы управлять студентами, курсами, преподавателями, факультетами и записями на курсы.

Схема базы данных:

  • Таблицы:
    • Students (Студенты):
      • student_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • major (character varying)
    • Courses (Курсы):
      • course_id (integer, Primary Key)
      • course_name (character varying)
      • course_code (character varying)
      • credits (integer)
      • department_id (integer, Foreign Key referencing Departments(department_id))
    • Professors (Преподаватели):
      • professor_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • department_id (integer, Foreign Key referencing Departments(department_id))
    • Departments (Факультеты):
      • department_id (integer, Primary Key)
      • department_name (character varying)
      • building (character varying)
    • Enrollments (Записи): (Таблица-связка - представляет студента, записанного на курс, который ведет преподаватель)
      • enrollment_id (integer, Primary Key) - Уникальный идентификатор каждой записи.
      • student_id (integer, Foreign Key referencing Students(student_id))
      • course_id (integer, Foreign Key referencing Courses(course_id))
      • professor_id (integer, Foreign Key referencing Professors(professor_id))
      • semester (character varying) - например, “Осень 2024”, “Весна 2025”.
      • grade (character varying, Nullable) - Оценка, полученная студентом (может быть null, если курс еще не завершен).
  • Связи:
    • Один-ко-многим между Departments и Courses.
    • Один-ко-многим между Departments и Professors.
    • Один-ко-многим между Students и Enrollments.
    • Один-ко-многим между Courses и Enrollments.
    • Один-ко-многим между Professors и Enrollments.
Вариант 4: База данных сервиса потоковой музыки

Сценарий: Спроектируйте базу данных для сервиса потоковой музыки, чтобы управлять исполнителями, альбомами, песнями, пользователями и плейлистами.

Схема базы данных:

  • Таблицы:
    • Artists (Исполнители):
      • artist_id (integer, Primary Key)
      • artist_name (character varying)
      • genre (character varying)
    • Albums (Альбомы):
      • album_id (integer, Primary Key)
      • album_name (character varying)
      • artist_id (integer, Foreign Key referencing Artists(artist_id))
      • release_year (integer)
    • Songs (Песни):
      • song_id (integer, Primary Key)
      • song_name (character varying)
      • album_id (integer, Foreign Key referencing Albums(album_id))
      • track_number (integer)
      • duration (integer) - Длительность в секундах.
    • Users (Пользователи):
      • user_id (integer, Primary Key)
      • username (character varying, unique)
      • email (character varying, unique)
      • registration_date (date)
    • Playlists (Плейлисты):
      • playlist_id (integer, Primary Key)
      • playlist_name (character varying)
      • user_id (integer, Foreign Key referencing Users(user_id))
      • creation_date (date)
    • Playlist_Songs (Песни_плейлиста): (Таблица-связка)
      • playlist_id (integer, Foreign Key referencing Playlists(playlist_id))
      • song_id (integer, Foreign Key referencing Songs(song_id))
      • (Составной первичный ключ: playlist_id, song_id)
      • added_date (timestamp)
  • Связи:
    • Один-ко-многим между Artists и Albums.
    • Один-ко-многим между Albums и Songs.
    • Один-ко-многим между Users и Playlists.
    • Один-ко-многим между Playlists и Playlist_Songs.
    • Один-ко-многим между Songs и Playlist_Songs.
Вариант 5: База данных каталога товаров для электронной коммерции

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

Схема базы данных:

  • Таблицы:
    • Products (Товары):
      • product_id (integer, Primary Key)
      • product_name (character varying)
      • description (text)
      • price (numeric)
      • category_id (integer, Foreign Key referencing Categories(category_id))
      • brand_id (integer, Foreign Key referencing Brands(brand_id))
      • supplier_id (integer, Foreign Key referencing Suppliers(supplier_id))
    • Categories (Категории):
      • category_id (integer, Primary Key)
      • category_name (character varying)
    • Brands (Бренды):
      • brand_id (integer, Primary Key)
      • brand_name (character varying)
    • Suppliers (Поставщики):
      • supplier_id (integer, Primary Key)
      • supplier_name (character varying)
      • supplier_contact (character varying)
    • Product_Reviews (Отзывы_о_товарах):
      • review_id (integer, Primary Key)
      • product_id (integer, Foreign Key referencing Products(product_id))
      • rating (integer) - например, от 1 до 5 звезд.
      • comment (text, Nullable)
      • review_date (timestamp)
  • Связи:
    • Один-ко-многим между Categories и Products.
    • Один-ко-многим между Brands и Products.
    • Один-ко-многим между Suppliers и Products.
    • Один-ко-многим между Products и Product_Reviews.
Вариант 6: База данных системы продажи билетов на мероприятия

Сценарий: Спроектируйте базу данных для системы продажи билетов на мероприятия, чтобы управлять событиями, местами проведения, билетами, покупателями и заказами.

Схема базы данных:

  • Таблицы:
    • Events (События):
      • event_id (integer, Primary Key)
      • event_name (character varying)
      • event_date (timestamp)
      • venue_id (integer, Foreign Key referencing Venues(venue_id))
    • Venues (Места_проведения):
      • venue_id (integer, Primary Key)
      • venue_name (character varying)
      • venue_address (character varying)
      • capacity (integer)
    • Tickets (Билеты):
      • ticket_id (integer, Primary Key)
      • event_id (integer, Foreign Key referencing Events(event_id))
      • ticket_type (character varying) - например, “Обычный вход”, “VIP”.
      • price (numeric)
      • quantity_available (integer)
    • Customers (Покупатели):
      • customer_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • email (character varying)
    • Orders (Заказы):
      • order_id (integer, Primary Key)
      • customer_id (integer, Foreign Key referencing Customers(customer_id))
      • order_date (timestamp)
    • Order_Tickets (Билеты_заказа): (Таблица-связка)
      • order_ticket_id (integer, Primary Key) - Уникальный идентификатор каждой позиции билета в заказе.
      • order_id (integer, Foreign Key referencing Orders(order_id))
      • ticket_id (integer, Foreign Key referencing Tickets(ticket_id))
      • quantity (integer)
      • price (numeric) - Цена билета на момент заказа.
  • Связи:
    • Один-ко-многим между Venues и Events.
    • Один-ко-многим между Events и Tickets.
    • Один-ко-многим между Customers и Orders.
    • Один-ко-многим между Orders и Order_Tickets.
    • Один-ко-многим между Tickets и Order_Tickets.
Вариант 7: База данных системы бронирования отелей

Сценарий: Спроектируйте базу данных для отеля, чтобы управлять номерами, гостями, бронированиями и удобствами.

Схема базы данных:

  • Таблицы:
    • Rooms (Номера):
      • room_id (integer, Primary Key)
      • room_number (character varying, unique within hotel) - уникальный в пределах отеля
      • room_type (character varying) - например, “Одноместный”, “Двухместный”, “Люкс”.
      • capacity (integer) - вместимость
      • price_per_night (numeric) - цена за ночь
    • Guests (Гости):
      • guest_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • phone_number (character varying)
      • email (character varying)
    • Reservations (Бронирования):
      • reservation_id (integer, Primary Key)
      • guest_id (integer, Foreign Key referencing Guests(guest_id))
      • room_id (integer, Foreign Key referencing Rooms(room_id))
      • check_in_date (date) - дата заезда
      • check_out_date (date) - дата выезда
      • number_of_guests (integer) - количество гостей
      • total_price (numeric) - общая стоимость
    • Amenities (Удобства):
      • amenity_id (integer, Primary Key)
      • amenity_name (character varying) - например, “Wi-Fi”, “Завтрак”, “Парковка”.
    • Room_Amenities (Удобства_номеров): (Таблица-связка для отношения “многие-ко-многим” между номерами и удобствами)
      • room_id (integer, Foreign Key referencing Rooms(room_id))
      • amenity_id (integer, Foreign Key referencing Amenities(amenity_id))
      • (Составной первичный ключ: room_id, amenity_id)
  • Связи:
    • Один-ко-многим между Rooms и Reservations.
    • Один-ко-многим между Guests и Reservations.
    • Один-ко-многим между Rooms и Room_Amenities.
    • Один-ко-многим между Amenities и Room_Amenities.
Вариант 8: База данных системы бронирования авиабилетов

Сценарий: Спроектируйте базу данных для авиакомпании, чтобы управлять рейсами, аэропортами, самолетами, пассажирами и бронированиями.

Схема базы данных:

  • Таблицы:
    • Flights (Рейсы):
      • flight_id (integer, Primary Key)
      • flight_number (character varying, unique) - уникальный номер рейса
      • departure_airport_id (integer, Foreign Key referencing Airports(airport_id)) - аэропорт отправления
      • arrival_airport_id (integer, Foreign Key referencing Airports(airport_id)) - аэропорт прибытия
      • departure_time (timestamp) - время отправления
      • arrival_time (timestamp) - время прибытия
      • aircraft_id (integer, Foreign Key referencing Aircrafts(aircraft_id)) - самолет
    • Airports (Аэропорты):
      • airport_id (integer, Primary Key)
      • airport_code (character varying, unique) - например, “JFK”, “LAX”, “CDG”.
      • airport_name (character varying)
      • city (character varying)
      • country (character varying)
    • Aircrafts (Самолеты):
      • aircraft_id (integer, Primary Key)
      • model (character varying) - например, “Boeing 737”, “Airbus A320”.
      • capacity (integer) - вместимость
    • Passengers (Пассажиры):
      • passenger_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • passport_number (character varying, unique) - уникальный номер паспорта
      • email (character varying)
    • Bookings (Бронирования):
      • booking_id (integer, Primary Key)
      • flight_id (integer, Foreign Key referencing Flights(flight_id))
      • passenger_id (integer, Foreign Key referencing Passengers(passenger_id))
      • booking_date (timestamp) - дата бронирования
      • seat_number (character varying) - номер места
      • fare (numeric) - стоимость билета
  • Связи:
    • Один-ко-многим между Airports и Flights (для аэропортов отправления и прибытия - две связи).
    • Один-ко-многим между Aircrafts и Flights.
    • Один-ко-многим между Passengers и Bookings.
    • Один-ко-многим между Flights и Bookings.
Вариант 9: База данных социальной сети (упрощенная)

Сценарий: Спроектируйте базу данных для упрощенной социальной сети, чтобы управлять пользователями, постами, комментариями и лайками.

Схема базы данных:

  • Таблицы:
    • Users (Пользователи):
      • user_id (integer, Primary Key)
      • username (character varying, unique) - уникальное имя пользователя
      • email (character varying, unique) - уникальный email
      • registration_date (timestamp) - дата регистрации
    • Posts (Посты):
      • post_id (integer, Primary Key)
      • user_id (integer, Foreign Key referencing Users(user_id))
      • post_text (text) - текст поста
      • post_timestamp (timestamp) - время создания поста
    • Comments (Комментарии):
      • comment_id (integer, Primary Key)
      • post_id (integer, Foreign Key referencing Posts(post_id))
      • user_id (integer, Foreign Key referencing Users(user_id))
      • comment_text (text) - текст комментария
      • comment_timestamp (timestamp) - время создания комментария
    • Likes (Лайки):
      • like_id (integer, Primary Key)
      • post_id (integer, Foreign Key referencing Posts(post_id))
      • user_id (integer, Foreign Key referencing Users(user_id))
      • like_timestamp (timestamp)
      • (Уникальное ограничение: post_id, user_id) - чтобы пользователь мог поставить лайк посту только один раз.
  • Связи:
    • Один-ко-многим между Users и Posts.
    • Один-ко-многим между Posts и Comments.
    • Один-ко-многим между Users и Comments.
    • Один-ко-многим между Posts и Likes.
    • Один-ко-многим между Users и Likes.
Вариант 10: База данных онлайн-рецептов

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

Схема базы данных:

  • Таблицы:
    • Recipes (Рецепты):
      • recipe_id (integer, Primary Key)
      • recipe_name (character varying)
      • description (text)
      • instructions (text)
      • category_id (integer, Foreign Key referencing Categories(category_id))
      • user_id (integer, Foreign Key referencing Users(user_id)) - Пользователь, создавший рецепт.
      • creation_date (date)
    • Ingredients (Ингредиенты):
      • ingredient_id (integer, Primary Key)
      • ingredient_name (character varying)
    • Recipe_Ingredients (Рецепты_Ингредиенты): (Таблица-связка)
      • recipe_id (integer, Foreign Key referencing Recipes(recipe_id))
      • ingredient_id (integer, Foreign Key referencing Ingredients(ingredient_id))
      • quantity (character varying) - например, “1 стакан”, “2 ст.л.”, “по вкусу”.
      • (Составной первичный ключ: recipe_id, ingredient_id)
    • Categories (Категории):
      • category_id (integer, Primary Key)
      • category_name (character varying) - например, “Завтрак”, “Обед”, “Ужин”, “Десерт”.
    • Users (Пользователи):
      • user_id (integer, Primary Key)
      • username (character varying, unique)
      • email (character varying, unique)
  • Связи:
    • Один-ко-многим между Categories и Recipes.
    • Один-ко-многим между Users и Recipes.
    • Один-ко-многим между Recipes и Recipe_Ingredients.
    • Один-ко-многим между Ingredients и Recipe_Ingredients.
Вариант 11: База данных агентства по прокату автомобилей

Сценарий: Спроектируйте базу данных для агентства по прокату автомобилей, чтобы управлять автомобилями, клиентами, прокатом и моделями автомобилей.

Схема базы данных:

  • Таблицы:
    • Cars (Автомобили):
      • car_id (integer, Primary Key)
      • license_plate (character varying, unique)
      • model_id (integer, Foreign Key referencing Car_Models(model_id))
      • mileage (integer)
      • availability_status (character varying) - например, “Доступен”, “В прокате”, “На обслуживании”.
    • Car_Models (Модели_автомобилей):
      • model_id (integer, Primary Key)
      • model_name (character varying) - например, “Седан”, “Внедорожник”, “Грузовик”.
      • make (character varying) - например, “Toyota”, “Ford”, “Honda”.
      • rental_rate_per_day (numeric)
    • Customers (Клиенты):
      • customer_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • driver_license_number (character varying, unique)
      • phone_number (character varying)
    • Rentals (Прокат):
      • rental_id (integer, Primary Key)
      • car_id (integer, Foreign Key referencing Cars(car_id))
      • customer_id (integer, Foreign Key referencing Customers(customer_id))
      • rental_start_date (date)
      • rental_end_date (date)
      • total_rental_price (numeric)
  • Связи:
    • Один-ко-многим между Car_Models и Cars.
    • Один-ко-многим между Customers и Rentals.
    • Один-ко-многим между Cars и Rentals.
Вариант 12: База данных системы управления обучением сотрудников

Сценарий: Спроектируйте базу данных для компании, чтобы управлять сотрудниками, учебными курсами, учебными сессиями и записями сотрудников на обучение.

Схема базы данных:

  • Таблицы:
    • Employees (Сотрудники):
      • employee_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • department (character varying)
      • job_title (character varying)
    • Training_Courses (Учебные_курсы):
      • course_id (integer, Primary Key)
      • course_name (character varying)
      • description (text)
      • duration_days (integer)
    • Training_Sessions (Учебные_сессии):
      • session_id (integer, Primary Key)
      • course_id (integer, Foreign Key referencing Training_Courses(course_id))
      • session_date (date)
      • location (character varying)
      • capacity (integer)
    • Employee_Trainings (Обучение_сотрудников): (Таблица-связка)
      • employee_training_id (integer, Primary Key) - Уникальный идентификатор каждой записи об обучении сотрудника.
      • employee_id (integer, Foreign Key referencing Employees(employee_id))
      • session_id (integer, Foreign Key referencing Training_Sessions(session_id))
      • enrollment_date (date)
      • completion_status (character varying) - например, “Записан”, “Завершено”, “Ожидает”.
      • grade (character varying, Nullable)
  • Связи:
    • Один-ко-многим между Training_Courses и Training_Sessions.
    • Один-ко-многим между Employees и Employee_Trainings.
    • Один-ко-многим между Training_Sessions и Employee_Trainings.
Вариант 13: База данных системы управления пациентами больницы

Сценарий: Спроектируйте базу данных для больницы, чтобы управлять пациентами, врачами, приемами, медицинскими записями и отделениями.

Схема базы данных:

  • Таблицы:
    • Patients (Пациенты):
      • patient_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • date_of_birth (date)
      • gender (character varying)
      • address (character varying)
      • phone_number (character varying)
    • Doctors (Врачи):
      • doctor_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • specialization (character varying)
      • department_id (integer, Foreign Key referencing Departments(department_id))
    • Departments (Отделения):
      • department_id (integer, Primary Key)
      • department_name (character varying) - например, “Кардиология”, “Неврология”, “Педиатрия”.
      • building (character varying)
    • Appointments (Приемы):
      • appointment_id (integer, Primary Key)
      • patient_id (integer, Foreign Key referencing Patients(patient_id))
      • doctor_id (integer, Foreign Key referencing Doctors(doctor_id))
      • appointment_date_time (timestamp)
      • reason_for_visit (text)
    • Medical_Records (Медицинские записи):
      • record_id (integer, Primary Key)
      • patient_id (integer, Foreign Key referencing Patients(patient_id))
      • record_date (date)
      • diagnosis (text)
      • treatment (text)
      • doctor_id (integer, Foreign Key referencing Doctors(doctor_id))
  • Связи:
    • Один-ко-многим между Departments и Doctors.
    • Один-ко-многим между Patients и Appointments.
    • Один-ко-многим между Doctors и Appointments.
    • Один-ко-многим между Patients и Medical_Records.
    • Один-ко-многим между Doctors и Medical_Records.
Вариант 14: База данных управления членством в тренажерном зале

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

Схема базы данных:

  • Таблицы:
    • Members (Члены):
      • member_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • date_of_birth (date)
      • email (character varying, unique)
      • phone_number (character varying)
      • membership_type_id (integer, Foreign Key referencing Membership_Types(membership_type_id))
      • join_date (date)
    • Trainers (Тренеры):
      • trainer_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • specialization (character varying)
    • Classes (Занятия):
      • class_id (integer, Primary Key)
      • class_name (character varying) - например, “Йога”, “Зумба”, “Спиннинг”.
      • description (text)
      • trainer_id (integer, Foreign Key referencing Trainers(trainer_id))
      • schedule_time (timestamp)
      • capacity (integer)
    • Membership_Types (Типы членства):
      • membership_type_id (integer, Primary Key)
      • membership_name (character varying) - например, “Базовый”, “Премиум”, “Семейный”.
      • price (numeric)
      • duration_months (integer)
    • Attendance (Посещаемость):
      • attendance_id (integer, Primary Key)
      • member_id (integer, Foreign Key referencing Members(member_id))
      • class_id (integer, Foreign Key referencing Classes(class_id))
      • attendance_date (date)
  • Связи:
    • Один-ко-многим между Membership_Types и Members.
    • Один-ко-многим между Trainers и Classes.
    • Один-ко-многим между Classes и Attendance.
    • Один-ко-многим между Members и Attendance.
Вариант 15: База данных системы штрафов за парковку

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

Схема базы данных:

  • Таблицы:
    • Parking_Tickets (Штрафы за парковку):
      • ticket_id (integer, Primary Key)
      • vehicle_id (integer, Foreign Key referencing Vehicles(vehicle_id))
      • officer_id (integer, Foreign Key referencing Parking_Officers(officer_id))
      • violation_id (integer, Foreign Key referencing Parking_Violations(violation_id))
      • ticket_issue_date_time (timestamp)
      • ticket_location (character varying)
      • fine_amount (numeric)
      • payment_status (character varying) - например, “Оплачен”, “Не оплачен”, “Просрочен”.
    • Vehicles (Транспортные средства):
      • vehicle_id (integer, Primary Key)
      • license_plate_number (character varying, unique)
      • make (character varying)
      • model (character varying)
      • color (character varying)
    • Parking_Officers (Сотрудники службы парковки):
      • officer_id (integer, Primary Key)
      • officer_badge_number (character varying, unique)
      • first_name (character varying)
      • last_name (character varying)
    • Parking_Violations (Нарушения правил парковки):
      • violation_id (integer, Primary Key)
      • violation_code (character varying, unique)
      • violation_description (text)
      • fine_amount (numeric)
  • Связи:
    • Один-ко-многим между Vehicles и Parking_Tickets.
    • Один-ко-многим между Parking_Officers и Parking_Tickets.
    • Один-ко-многим между Parking_Violations и Parking_Tickets.
Вариант 16: База данных службы доставки еды

Сценарий: Спроектируйте базу данных для службы доставки еды, чтобы управлять ресторанами, клиентами, заказами, курьерами и позициями меню.

Схема базы данных:

  • Таблицы:
    • Restaurants (Рестораны):
      • restaurant_id (integer, Primary Key)
      • restaurant_name (character varying)
      • address (character varying)
      • phone_number (character varying)
      • cuisine_type (character varying)
    • Customers (Клиенты):
      • customer_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • address (character varying)
      • phone_number (character varying)
      • email (character varying)
    • Delivery_Drivers (Курьеры):
      • driver_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • vehicle_type (character varying) - например, “Автомобиль”, “Велосипед”, “Скутер”.
    • Orders (Заказы):
      • order_id (integer, Primary Key)
      • customer_id (integer, Foreign Key referencing Customers(customer_id))
      • restaurant_id (integer, Foreign Key referencing Restaurants(restaurant_id))
      • driver_id (integer, Foreign Key referencing Delivery_Drivers(driver_id), Nullable) - Курьер, назначенный на заказ (изначально Null).
      • order_date_time (timestamp)
      • delivery_address (character varying)
      • order_status (character varying) - например, “Ожидает”, “Готовится”, “В пути”, “Доставлен”.
      • total_amount (numeric)
    • Menu_Items (Позиции меню):
      • menu_item_id (integer, Primary Key)
      • restaurant_id (integer, Foreign Key referencing Restaurants(restaurant_id))
      • item_name (character varying)
      • description (text)
      • price (numeric)
  • Связи:
    • Один-ко-многим между Restaurants и Menu_Items.
    • Один-ко-многим между Customers и Orders.
    • Один-ко-многим между Restaurants и Orders.
    • Один-ко-многим между Delivery_Drivers и Orders (nullable foreign key).
Вариант 17: База данных кинотеатра для продажи билетов

Сценарий: Спроектируйте базу данных для кинотеатра, чтобы управлять фильмами, сеансами, кинозалами, билетами и клиентами.

  • Таблицы:
    • Movies (Фильмы):
      • movie_id (integer, Primary Key)
      • movie_title (character varying)
      • genre (character varying)
      • duration_minutes (integer)
      • release_date (date)
    • Theaters (Кинозалы):
      • theater_id (integer, Primary Key)
      • theater_name (character varying) - например, “Зал 1”, “IMAX Зал”.
      • capacity (integer)
    • Screenings (Сеансы):
      • screening_id (integer, Primary Key)
      • movie_id (integer, Foreign Key referencing Movies(movie_id))
      • theater_id (integer, Foreign Key referencing Theaters(theater_id))
      • start_time (timestamp)
      • end_time (timestamp)
      • ticket_price (numeric)
    • Customers (Клиенты):
      • customer_id (integer, Primary Key)
      • first_name (character varying)
      • last_name (character varying)
      • email (character varying)
    • Tickets (Билеты):
      • ticket_id (integer, Primary Key)
      • screening_id (integer, Foreign Key referencing Screenings(screening_id))
      • customer_id (integer, Foreign Key referencing Customers(customer_id))
      • seat_number (character varying)
      • purchase_date_time (timestamp)
  • Связи:
    • Один-ко-многим между Movies и Screenings.
    • Один-ко-многим между Theaters и Screenings.
    • Один-ко-многим между Screenings и Tickets.
    • Один-ко-многим между Customers и Tickets.
Вариант 18: База данных управления запасами на производстве

Сценарий: Спроектируйте базу данных для производственной компании, чтобы управлять продуктами, сырьем, поставщиками, запасами и заказами.

  • Таблицы:
    • Products (Продукты):
      • product_id (integer, Primary Key)
      • product_name (character varying)
      • description (text)
      • selling_price (numeric)
    • Raw_Materials (Сырье):
      • material_id (integer, Primary Key)
      • material_name (character varying)
      • unit_of_measurement (character varying) - например, “кг”, “литры”, “штуки”.
      • supplier_id (integer, Foreign Key referencing Suppliers(supplier_id))
      • cost_per_unit (numeric)
    • Suppliers (Поставщики):
      • supplier_id (integer, Primary Key)
      • supplier_name (character varying)
      • contact_person (character varying)
      • phone_number (character varying)
    • Inventory (Запасы):
      • inventory_id (integer, Primary Key)
      • material_id (integer, Foreign Key referencing Raw_Materials(material_id))
      • quantity_in_stock (integer)
      • last_stock_update (timestamp)
    • Production_Orders (Производственные заказы):
      • order_id (integer, Primary Key)
      • product_id (integer, Foreign Key referencing Products(product_id))
      • order_date (date)
      • quantity_ordered (integer)
      • status (character varying) - например, “Ожидает”, “В производстве”, “Завершен”.
  • Связи:
    • Один-ко-многим между Suppliers и Raw_Materials.
    • Один-ко-многим между Raw_Materials и Inventory.
    • Один-ко-многим между Products и Production_Orders.

Инструкции по сдаче:

Шаг 1. Сделайте высококачественный снимок экрана вашей ER-диаграммы

  1. Разверните холст ERD: В pgAdmin 4 убедитесь, что вся ваша ER-диаграмма видна на экране. Возможно, вам потребуется немного уменьшить масштаб или снова использовать функцию “Auto Align” (Автовыравнивание), чтобы все таблицы и связи были четко видны, не перекрывались и не обрезались.

  1. Сделайте снимок экрана: Сделайте снимок экрана всего окна pgAdmin 4, четко показывая созданную вами ER-диаграмму.
  2. Проверьте качество снимка экрана: Откройте снимок экрана и убедитесь, что:
    • Видна вся ER-диаграмма.
    • Названия таблиц, названия столбцов, типы данных, первичные ключи, внешние ключи и связи четко читаются.
    • Снимок экрана не размыт и не пикселизирован. Если он нечеткий, сделайте снимок экрана повторно.
  3. Сохраните снимок экрана: Сохраните снимок экрана как файл изображения (например, .png, .jpg). Назовите файл информативно, например, Variant[Номер варианта]_ERD_Screenshot_[ВашаФамилия]_[ВашеИмя].png (например, Variant1_ERD_Screenshot_Иванов_Иван.png).

Шаг 2: Загрузите снимок экрана на Google Диск

  1. Откройте Google Диск: Перейдите в свою учетную запись Google Диска в веб-браузере.
  2. Перейдите в папку для сдачи (необязательно, но рекомендуется): Вы можете создать новую папку на своем Google Диске специально для этого курса баз данных или для сдачи заданий, чтобы все было организовано.
  3. Загрузите файл: Нажмите кнопку “+ Создать” (или “Загрузить”) и выберите “Загрузить файлы”. Выберите файл изображения снимка экрана, который вы сохранили на шаге 7. Дождитесь завершения загрузки.

Шаг 3: Настройте права доступа к снимку экрана на Google Диске

  1. Найдите загруженный файл: Найдите файл снимка экрана, который вы только что загрузили, на своем Google Диске.
  2. Получите ссылку для общего доступа: Щелкните правой кнопкой мыши по файлу снимка экрана и выберите “Получить ссылку” (или “Поделиться”).
  3. Измените настройки ссылки: В появившемся диалоговом окне совместного доступа нажмите “Изменить” рядом с “Ограниченный доступ” (или текущей настройкой доступа).
  4. Выберите “Всем, у кого есть ссылка”: Выберите опцию “Всем, у кого есть ссылка” из раскрывающегося меню.
  5. Установите разрешение “Читатель” (Viewer): Убедитесь, что установлено разрешение “Читатель” (оно должно быть установлено по умолчанию).
  6. Скопируйте ссылку: Нажмите кнопку “Копировать ссылку”. Ссылка на ваш снимок экрана теперь скопирована в буфер обмена.
  7. Нажмите “Готово”: Закройте диалоговое окно совместного доступа.

Шаг 4: Отправьте ссылку на Google Диск в Google Таблицы

  1. Откройте Google Таблицу: Google Таблица
  2. Найдите свою строку: Найдите свое имя или идентификатор студента в первом столбце Google Таблицы. Ваша ячейка для сдачи будет находиться в соответствующей строке.
  3. Вставьте ссылку в виде комментария:
    • Нажмите на ячейку, предназначенную для вашей сдачи.
    • Щелкните правой кнопкой мыши по ячейке и выберите “Вставить комментарий” (или “Комментарий”).
    • Вставьте ссылку на Google Диск, которую вы скопировали на шаге 3, в поле комментария.
    • Нажмите “Комментировать” или кнопку “Опубликовать”, чтобы сохранить комментарий со ссылкой.
  4. Проверьте отправку: Дважды проверьте, что ваш комментарий виден в ячейке и что вы правильно вставили ссылку.

Важные напоминания:

  • Убедитесь, что на Google Диске установлен доступ “Всем, у кого есть ссылка, разрешено просматривать”. Если это не настроено правильно, ваш преподаватель не сможет увидеть ваш снимок экрана.
  • Проверьте свою ссылку! Откройте ссылку в режиме инкогнито или на другом устройстве, чтобы убедиться, что она работает должным образом и отображает ваш снимок экрана.
  • Сдайте работу до указанного срока. Проверьте инструкции к заданию, чтобы узнать крайний срок сдачи.