Файл: Практическая работа 1 Преобразование реляционной бд в сущности и связи Цель работы выработать.docx

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

• 
  Какие спектакли идут в определенный день?
  
• 
  Есть ли билеты на конкретный спектакль?
  
• 
  Сколько стоит конкретный билет? Вариант 4.
  

Описание предметной области (Грузоперевозки).АТПимеетгрузовыеавтомобилисгос.номерамииорганизуетперевозкидлясвоихзаказчиков.Стоимостьперевозкизависитотрасстоянияигрузоподъемностиавтомобиля,которыйеевыполняет.Каждыйзаказчикможетсделатьзаказнесколькихперевозок.Однуперевозкувыполняет один грузовик.Задачи для БД:

• 
  Какие грузовики свободны?
  
• 
  Какой заказчик сделал самый дорогой заказ?
  
• 
  Какой грузовик выполнил наибольшее количество заказов?
  

Технологиявыполненияработы

1. 
   ПостроениеER-диаграммы.
   

1. 
   Выберите из описания предметной области все существительные. Продумайте, какие из них будут соответствовать сущностям, а какие атрибутам сущностей. Зарисуйте в отчет все сущности с их атрибутами согласно обозначениям, принятым в ER-диаграммах.
   
2. 
   На рисунке подчёркиванием атрибутов обозначьте для каждой сущности уникальный идентификатор (Ключ). При необходимости добавьте сущностям атрибуты, которые помогут однозначно отличить каждый экземпляр сущности.
   
3. 
   Определите и включите в схему связи сущностей. Подпишите названия связей и пронумеруйте связи. Для первой связи укажите тип и модальность. Для всех связей запишите их прочтение слева направо и справа налево.
   
4. 
   Если в схеме присутствуют связи типа «много-со-многими» уберите их путем ввода дополнительной сущности. Измененную схему зарисуйте в отчет.
   
1. 
   . Получениереляционной схемы изER-диаграммы.
   
   1. 
      Каждая сущность превращается в таблицу. Имя сущности – имя таблицы. Набор всех таблиц – БД. Вспомните, что такое схема БД. Запишите схему вашей БД в отчет.
      
   2. 
      Зарисуйте все полученные таблицы с их заголовками и названиями столбцов. Выделите потенциальные и внешние ключи (если есть) для каждой таблицы. Укажите столбцы, допускающие неопределенные значения.
      
   3. 
      Докажите, что полученные отношения находятся в Первой нормальной форме. (Первая нормальная форма (1NF) — это свойство отношения в реляционной базе данных. Отношение находится в первой нормальной форме тогда и только тогда, когда ни один домен атрибутов не имеет отношений в качестве элементов. Или более неформально, что ни один столбец таблицы не может иметь таблиц в качестве значений (или повторяющихся групп).)
      

---

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

---

Конструкции, нарушающие 1NF

Эта таблица транзакций по кредитным картам клиентов не соответствует первой нормальной форме:

Заказчик	Идентификатор клиента	Транзакции
Абрахам	1	Идентификатор транзакции Дата Сумма 12890 14 октября 2003 −87 12904 15 октября 2003 −50
Исаак	2	Идентификатор транзакции Дата Сумма 12898 14 октября 2003 −21
Джейкоб	3	Идентификатор транзакции Дата Сумма 12907 15 октября 2003 −18 14920 20 ноября 2003 −70 15003 27 ноября 2003 −60

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

---

1. 
   Распаковка одной или нескольких групп транзакций клиентов, позволяющая проверять отдельные транзакции в группе, и
   
2. 
   Получение результата запроса на основе результатов первого этапа
   

Например, чтобы узнать денежную сумму всех транзакций, которые произошли в октябре 2003 года для всех клиентов, система должна знать, что она должна сначала распаковать группу транзакций каждого клиента, а затем суммировать суммы всех транзакций, полученных таким образом, где дата транзакции приходится на октябрь 2003 года.Одной из важных идей Кодда было то, что структурную сложность можно уменьшить. Уменьшенная структурная сложность дает пользователям, приложениям и СУБД больше возможностей и гибкости для формулирования и оценки запросов. Более нормализованный эквивалент приведенной выше структуры может выглядеть следующим образом:

Конструкции, соответствующие 1NF

Чтобы привести модель к первой нормальной форме, мы можем выполнить нормализацию. Нормализация (до первой нормальной формы) - это процесс, при котором атрибуты с непростыми доменами извлекаются для разделения автономных отношений. Извлеченные отношения дополняются внешними ключами, ссылающимися на первичный ключ отношения, которое его содержало. Процесс может быть применен рекурсивно к непростым доменам, вложенным в несколько уровней.^[4]В этом примере идентификатор клиента является первичным ключом содержащих отношений и поэтому будет добавлен в качестве внешнего ключа к новому отношению:

Заказчик	Идентификатор клиента
Абрахам	1
Исаак	2
Джейкоб	3

Идентификатор клиента	Идентификатор транзакции	Дата	Сумма
1	12890	14 октября 2003	−87
1	12904	15 октября 2003	−50
2	12898	14 октября 2003	−21
3	12907	15 октября 2003	−18
3	14920	20 ноября 2003	−70
3	15003	27 ноября 2003	−60

---

В измененной структуре первичным ключом является {Идентификатор клиента} в первом отношении, {Идентификатор клиента, идентификатор транзакции} во втором отношении.Теперь каждая строка представляет отдельную транзакцию по кредитной карте, и СУБД может получить интересующий ответ, просто найдя все строки с датой, приходящейся на октябрь, и суммируя их суммы. Структура данных размещает все значения на равных основаниях, предоставляя каждое из них напрямую СУБД, поэтому каждое потенциально может напрямую участвовать в запросах; тогда как в предыдущей ситуации некоторые значения были встроены в структуры более низкого уровня, которые должны были обрабатываться особым образом. Соответственно, нормализованный дизайн подходит для обработки запросов общего назначения, в то время как ненормализованный дизайн - нет.Стоит отметить, что эта конструкция отвечает дополнительным требованиям для второй и третьей нормальной формы.

---