Ход работы с пояснениями

Задание:

1. 
   Воспроизвести концептуальную схему БД по заданному образцу (ftp://ftp.vt.tpu.ru/study/Shestakov/Public/database/Labs/Концептуальна схема.png) в TDM.
   
2. 
   Преобразовать концептуальную схему в физическую (для MS SQL Server 2008).
   
3. 
   Произвести необходимые изменения физической схемы перед разворачиванием её на Sql Server. Проверить корректность внешних ключей.
   
4. 
   Сгенерировать скрипт создания БД и применить его на своей (вновь созданной) БД.
   
5. 
   Проверить, что схема создана корректно. Создать диаграмму БД средствами Sql Server.
   
6. 
   Внести изменения в концептуальную схему (придумать самому, например, добавить новый атрибут в одну из сущностей)
   
7. 
   Распространить внесённые изменения на физическую схему и на схему БД на сервере.
   

Ход работы с пояснениями.

1. 
   Создать концептуальную схему БД (Logical Data Model в TDM). В схеме должны быть корректно учтены:
   

• 
  Идентификаторы сущностей (unique identifiers). Должны присутствовать первичные (PUI) и, где необходимо, альтернативные (UI). Желательно давать осмысленные имена названиям идентификаторов. Например, PUI таблицы «Автобусы» назвать «ПК_Автобусы», альтернативный UI назвать «АК_Автобусы» (или можете придумать свой стиль наименования). Именование идентификаторов и других ограничений целостности может помочь в дальнейшем в разборе ошибок, возвращаемых при верификации модели в TDM или при выполнении скриптов в SQL Server, поскольку сообщения об ошибках будут ссылаться на эти имена. Также необходимо учитывать, что TDM не следит за уникальностью названий идентификаторов в концептуальной схеме (в физической следит при верификации), и может получиться так, что названия, предложенные TDM по умолчанию, будут конфликтовать друг с другом.
  
• 
  Типы атрибутов сущностей. Для первичных суррогатных идентификаторов должен быть создан отдельный тип (домен) DOM_GUID, базовым типом которого указать BigInt (на самом деле, должен быть Uniqueidentifier, но такой тип не поддерживается в концептуальных схемах TDM).
  
• 
  Обязательность (Mandatory) атрибутов сущностей.
  
• 
  Типы связей (relationships):
  
  • 
    Идентифицирующая (identifying)/неидентифицирующая (non-identifying)
    
  • 
    По кардинальности. В нашем случае – везде 1:М, главное – не перепутать, где 1, а где М.
    
• 
  Обязательность (Mandatory) связей (со стороны 1). Можно настроить в свойствах связи.
  
• 
  Принимайте во внимание, что диаграмма может отображать не все элементы модели (полный список объектов можно посмотреть в дереве в Model Explorer). При попытке удаления объекта с диаграммы TDM отображает диалог:
  
  Выбор по умолчанию удалит только изображение объекта, но не сам объект. Чтобы удалить элемент полностью, нужно выбрать второй вариант (Delete from model).
  

2. 
   Создать из концептуальной схемы (Logical Data Model в TDM) реляционную схему для выбранной СУБД SQL Server 2008 (Physical Data Model в TDM), также называемую физической, т.к. она содержит в себе специфику выбранной СУБД, т.е. затрагивает не только логический, но и физический этап проектирования.
   File -> Sync & Convert -> Simple Convert
   В качестве СУБД, разумеется, выбирается SQL Server 2008.
   Следить за названиями схем. Категорически рекомендуется в название схемы включать свою фамилию, чтобы не перепутать с о схемами других студентов, работавших на этом компьютере. Концептуальную схему называть концептуальной, физическую – физической (не оставлять названия, предлагаемые Toad по умолчанию).
   Далее в тексте будем ссылаться на полученную физическую схему PDM1.
   
3. 
   В PDM1 сменить тип данных домена DOM_GUID на uniqueidentifier. На концептуальном уровне выбрать этот тип сразу было невозможно (Toad не поддерживает uniqueidentifier на уровне Logical Data Model). На уровне Physical Data Model нам доступны все типы SQL Server 2008, поэтому теперь это становится возможным.
   В некоторых таблицах имеется два ключа (первичный и альтернативный). По умолчанию Toad создаёт для ключей кластерные индексы, но в одной таблице только один ключ может быть кластерным. Поэтому в свойствах одного из ключей необходимо убрать флажок «Clustered». В противном случае будет ошибка при верификации модели, а при попытке запустить DDL-скрипт ошибку выдаст SQL Server (невозможно создать более одного кластерного индекса).
   
4. 
   Если верификация физической схемы проходит успешно, можно сгенерировать DDL-скрипт (Model -> Generate DDL script). Полученный файл скрипта нужно открыть в Management Studio и запустить на новой созданной пустой базе данных. Скрипт должен создать все объекты схемы БД: таблицы, первичные и альтернативные ключи, внешние ключи.
   
5. 
   Далее попытаемся отработать сценарий, в котором нам нужно внести изменения в концептуальную схему и распространить эти изменения вниз на физический уровень. Изменение придумать самостоятельно (можно добавить новый атрибут, создать ещё один домен и включить некоторые атрибуты в этот домен, исправить допущенную ранее ошибку и т.п.)
   
6. 
   Toad не позволяет применить напрямую изменения концептуальной схемы на физическую. Для этого сначала придётся создать временную физическую схему, после чего выполнить слияние временной схемы и изначальной схемы (PDM1). Конвертируем концептуальную схему во временную физическую схему (в тексте будем ссылаться на неё, как на PDM2).
   
7. 
   Далее запустим мастер слияния: File -> Sync & Convert -> Wizard -> Merge. В качестве Source Model выбираем PDM2 (источник наших изменений), в качестве Destination – PDM1 (исходная схема). Когда мастер отобразит список различий между схемами, необходимо выбрать (отметить галочками) только те различия, которые возникли по причине изменений концептуальной схемы и не отмечать остальные (которые существуют из-за изменений, внесённых в физическую схему в п.2).
   По идее, merge должен выполняться в схему, указанную как destination (т.е. в PDM1). Но для первого раза безопаснее выбрать для этого новую схему (Merge to new model), чтобы случайно не испортить изначальную схему PDM1.
   
8. 
   Теперь у обновлённой физической схемы, полученной после слияния, должны остаться изменения, внесённые в п.2 (тип домена DOM_GUID должен быть uniqueidentifier, и альтернативные ключи должны быть некластерными). В то же время, должны присутствовать и изменения, внесённые в концептуальную схему. После этого нужно заново сгенерировать DDL-скрипт и выполнить его на своей базе данных. Если скрипт генерировать с опцией «DROP, CREATE», то будут созданы инструкции для удаления объектов схемы, после чего инструкции для создания, то есть, скрипт можно будет запустить на базе, не удаляя из неё таблицы вручную (это сделает скрипт). Хотя инструкции удаления некоторых объектов, которых нет в БД, и выполнятся с ошибкой.
   

Содержание отчёта

• 
  Концептуальная схема БД
  
• 
  Физическая схема БД (PDM1)
  
• 
  Концептуальная схема БД после внесения изменений (или элементы схемы, на которых видны изменения)
  
• 
  Диалог слияния физических схем (на нём видно, какие различия между схемами будут выбраны для применения на конечной схеме)
  
• 
  Физическая схема БД после слияния