Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
БД3-ПроектированиеБД.docx
Скачиваний:
2
Добавлен:
16.09.2019
Размер:
24.17 Кб
Скачать

Этапы выполнения ИДЗ

  1. Концептуальное проектирование (концептуальная схема в Toad Data Modeler)

  2. Логическое проектирование (реляционная схема в Toad Data Modeler)

  3. Физическое проектирование:

    1. Создание БД в SQL Server

    2. Создание 1 хранимой процедуры и 1 представления (согласовать с преподавателем)

    3. Настройка прав доступа (согласовать с преподавателем), раздача прав на созданные объекты БД (таблицы, представление, процедура)

  1. Супермаркет (БД товаров и покупок)

Хранить информацию о товарах, сгруппированных по категориям, ценах на товары, историю изменения цен на товары.

При отбитии чека на кассе магазина информация о покупке сохраняется в БД (время, № кассы, кассир, список покупок с оплатой и т.п.).

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

  1. Энциклопедия футбольной статистики (игры)

Хранить результаты футбольных матчей в различных турнирах. Для каждого матча должно быть известно: турнир, стадия турнира (отборочные игры в группе, четвертьфинал, полуфинал, финал и т.д.), играющие команды, состав (игроки, тренер, замены), судьи, нарушения (желтые карточки, удаления), забитые мячи (время, кто забил), счет первого тайма, счет в серии пенальти (если было), итоговый счет матча, итоговый счет по результатам двух матчей (если победитель определяется по результатам двух встреч).

  1. Энциклопедия футбольной статистики (игроки)

Хранить карьерную историю футболистов. БД должна быть в состоянии предоставить информацию об игроках, тренерах, клубах, выигранных трофеях. Для каждого игрока должно быть известно: позиция на поле, в каких клубах он играл, когда переходил из одного клуба в другой или был сдан в аренду, количество игр за клуб в сезоне, количество забитых/пропущенных за клуб мячей. Для тренеров должно быть известно, какие клубы когда тренировал. Игроки могут быть одновременно и тренерами (играющий тренер), тренеры в прошлом иметь карьеру игрока.

  1. Система отслеживания ошибок (bug tracker)

В БД должна храниться информация и история по найденным и исправленным ошибкам.

Для каждой найденной ошибки создается рапорт об ошибке, в котором указывается: область возникновения ошибки (из списка), ответственный разработчик, состояние ошибки, описание ошибки, создатель рапорта.

Разработчики могут дописывать к описанию комментарии и менять состояние ошибки («исправлено», «отложено», «в процессе исправления», «закрыто» и т.п.)

Часть состояний относятся к «активным» («обнаружено», «в процессе исправления», «отложено»), часть – к «неактивным» («исправлено», «закрыто», «не может быть исправлено», «не является ошибкой»).

Все комментарии, добавленные разработчиками, должны сохраняться (и быть доступны при просмотре ошибки в системе отслеживания ошибок). Все изменения состояний ошибок тоже должны сохраняться, чтобы было можно просмотреть, кто и когда эти состояния изменял.

  1. Онлайн рпг

Хранить информацию о персонажах, неигровых персонажах (NPC), монстрах, предметах, используемых в игре, о размещении предметов на игровой карте (или у персонажей). Предметы могут быть различных категорий, каждый предмет может увеличивать или уменьшать некоторую характеристику персонажа.

Персонажи в игре делятся на классы, каждый класс определяет изначальные значения характеристик персонажа.

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

Кроме персонажей, которыми управляют игроки, на игровой карте размещены «монстры» и NPC. Они также обладают набором характеристик, но управляются искусственным интеллектом игры. Монстры и NPC тоже делятся на классы, но опыт не накапливают.

  1. Поликлиника

Хранить информацию о врачах поликлиники (ФИО, специальность, часы приёма), посетителях (номер полиса, адрес и т.п.).

Посетители могут приходить в поликлинику на приём к врачу. Приём может включать в себя процедуры (а может и не включать). На приём посетитель может прийти по направлению врача поликлиники, либо без направления (например, просто по предварительной записи, или по направлению из другой поликлиники, данных по которой в БД нет).

Врачи осуществляют приём посетителей и проведение процедур (УЗИ, флюорография и т.п.). В результате каждого приёма пишется диагноз, рецепт, направления к другим врачам, направление на повторный приём (не обязательно всё вместе).

  1. Сотовая связь – база абонентов

Оператор сотовой связи предоставляет несколько тарифов.

Абоненты, подключённые к сети оператора, имеют некоторый номер (или несколько номеров), каждый номер подключается к определенному тарифу.

Для каждого тарифа определяется абонентская плата, тип подсчета времени (посекундно, поминутно и т.п.), стоимость вызовов на номера внутри сети, внутри области, в пределах РФ, и т.п.

Кроме тарифов существуют подключаемые опции. Каждая опция определяет уточнённую стоимость услуг при каких-либо условиях (например, бесплатные звонки ночью в течение месяца за определённую разовую стоимость). Опции могут подключаться к определённым тарифам (не для всех тарифов возможно подключение определённых опций).

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

  1. Музыкальный портал

Некоторый интернет-сайт предоставляет сервис по прослушиванию и скачиванию музыкальных композиций.

Нужно хранить информацию об исполнителях (группы, ансамбли, оркестры, сольные исполнители…), альбомах (как альбомы групп, так и сборники), композициях.

Зарегистрированные пользователи сайта могут прослушивать композиции, скачивать, отмечать «любимых» исполнителей. История прослушиваний сохраняется в БД (например, для последующего анализа предпочтений и построения статистики).

  1. БД дискографий (энциклопедия)

БД энциклопедии должна хранить информацию о следующих сущностях.

Музыканты (как в роли исполнителей, так и композиторов), коллективы (группы, ансамбли, оркестры…), альбомы (как альбомы групп, так и сборники), композиции. Для каждого коллектива хранить состав с историей (кто когда вышел из состава или пришёл). Для каждой композиции указывать исполнителя, авторов (композиторов).

  1. Ремонты оборудования

Необходимо создать БД для системы управления ремонтами. Ремонты производятся над оборудованием, которое состоит на балансе предприятия. Ремонты подразделяются на плановые (техобслуживания) и незапланированные (по состоянию оборудования). Плановые техобслуживания выполняются с определённой периодичностью (например, раз в полгода, два раза в месяц, раз в два года и т.п.) Периодичность может быть разной для разного оборудования.

БД должна включать: перечень оборудования предприятия, периодичность ремонтов, график запланированных ремонтов (техобслуживаний) на каждый год, журнал выполненных ремонтов (как запланированных, так и не запланированных).