Связь «многие ко многим»
Связь «многие ко многим» может быть создана только на уровне логической модели. На рис. 55 показан пример связи «многие ко многим». Врач может принимать много пациентов, пациент может лечиться у нескольких врачей. Такая связь обозначается сплошной линией с двумя точками на концах Рис. 55. Пример связи «многие ко многим». Для внесения связи следует установить курсор на кнопке на панели инструментов ERwin, щелкнуть по одной, затем по другой сущности. Связь «многие ко многим» должна именоваться двумя фразами — в обе стороны (в примере «лечит/лечится у»). Это облегчает чтение диаграммы. Связь на рис. 55 следует читать так: Врач Пациента, Пациент Врача .
На физическом уровне связь «многие ко многим» должна быть преобразована. По умолчанию при переходе к физическому уровню ERwin DM автоматически не преобразует связь «многие ко многим», и на физическом уровне диаграмма выглядит так же, как и на логическом (рис. 55). Однако при генерации схемы такая связь игнорируется. Для преобразования связи «многие ко многим» необходимо щелкнуть по связи правой кнопкой мыши и выбрать пункт меню Create Association Table или выбрать связь и щелкнуть по инструменту на панели трансформаций ERwin Transform Toolbar (см. табл. 5). (Подробнее операции преобразования будут рассмотрены разделе «Трансформации».) Появляется Мастер трансформаций — Many-To-Many Transform Wizard, состоящий из 4 шагов-диалогов. Для перехода к следующему шагу надо щелкнуть по кнопке Next (Далее). На втором и третьем шаге следует задать имя вновь создаваемой таблицы и имя преобразования. Преобразование связи включает создание новой таблицы и двух новых связей «один ко многим» от старых к новой таблице (рис.56). При этом имя новой таблице присваивается как Имя1_Имя2 . Рис. 56. Пример автотрансформации связи «многие ко многим». Описанного выше решения проблемы связи «многие ко многим» не всегда оказывается достаточно. В примере таблица Врач_Пациент имеет смысл визита к врачу, поэтому ее следует переименовать согласно бизнеслогике в Посещение . Один и тот же пациент может много раз посещать врача, поэтому для того, чтобы идентифицировать визит, необходимо в состав первичного ключа таблицы Посещение добавить дополнительную колонку, например дату-время посещения ( ДатаВремяПосещения , рис. 57). Следует заметить, что после переименования таблицы на физическом уровне на логическом уровне представление модели не изменится, диаграмма будет выглядеть так, как на рис. 56. Рис. 57. Пример дополнения физического уровня модели после трансформации связи «многие ко многим».
Типы зависимых сущностей
Как было указано выше, связи определяют, является ли сущность независимой или зависимой. Различают несколько типов зависимых сущностей. Характеристическая — зависимая дочерняя сущность (рис.58), которая связана только с одной родительской и по смыслу хранит информацию о характеристиках родительской сущности. Рис. 58. Пример характеристической сущности «Хобби». Ассоциативная — сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей. Примером ассоциативной сущности является Посещение на рис. 57. Именующая — частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа). Примером именующей сущности является Врач_Пациент на рис. 56. Категориальная — дочерняя сущность в иерархии наследования (см. ниже).
Иерархия категорий (иерархия наследования).
Представление об иерархиях категорий, их типах и отображении в нотациях IDEF1X, IE было дано в разделе «Особенности методологий IDEF1X и IE». Рассмотрим возможные стадии построения иерархии наследования. А) Определение сущностей с общими (но определению) атрибутами. Предположим, в процессе проектирования созданы сущности Посто- янный сотрудник и Совместитель (рис. 59). Можно заметить, что часть атрибутов у этих сущностей ( Фамилия, Имя, Отчество, Дата рожде- ния, Должность ) имеет одинаковый смысл. Рис. 59. Сущности с общими по смыслу атрибутами. В случае обнаружения совпадающих по смыслу атрибутов следует создать новую сущность ( Сотрудник ) — родовой предок и перенести в нее общие атрибуты.
Б) Создание неполной структуры категорий . Создается категориальная связь от новой сущности — родового предка к старым сущностямпотомкам. Новая сущность дополняется атрибутом-дискриминатором категории ( Тип ) (рис. 60). Рис. 60. Пример неполной иерархии категорий. Рис. 61. Диалог Subtype Properties. Для создания категориальной связи следует: левой кнопкой мышки щелкнуть по кнопке (см. табл. 11); щелкнуть сначала по родовому предку, а затем по потомку;
для установления второй связи в иерархии категории сначала щелкнуть по символу категории, затем по второму (третьему и т.д.) потомку. Для редактирования категорий нужно щелкнуть правой кнопкой мыши по символу категории и выбрать в контекстном меню пункт Subtype Properties. В диалоге Subtype Properties (рис. 61) можно указать атрибут- дискриминатор категории Тип (список Discriminator) и тип категории — Incomplete – неполная (раздел Type: опции Complete/Incomplete — полная/неполная). В) Создание полной структуры категорий . Проводится дополнительный поиск сущностей, имеющих общие по смыслу атрибуты с родовым предком. В примере это сущность Консультант (рис. 62). Общие атрибуты переносятся в родового предка, и категория преобразуется в полную. Признак полной категории устанавливается в диалоге Subtype RelationРис. 62. Дополниship (в разделе Type следует выбрать опцию Complete ). тельная сущность. Сущность Консультант не имеет атрибута Должность , поэтому в родовом предке значение этого атрибута в случае консультанта будет NULL. В зависимости от бизнес-правил атрибут Должность может быть перенесен обратно из родового предка в сущно- сти-потомки Постоянный сотрудник и Совместитель или может быть принято решение о том, что для консультанта также требуется указывать должность (рис. 63). Рис. 63. Пример полной иерархии категорий. Г) Пример комбинации полной и неполной категорий показан на рис.64. Согласно представленному на рисунке фрагменту модели сотрудник может быть совместителем или постоянным сотрудником (неполная категория, т.к. не отображены сотрудники-консультанты), а постоянный сотрудник является любо мужчиной либо женщиной (полная категория).
Ошибка HTTP 500.19 — внутренняя ошибка сервера при открытии веб-страницы IIS
В этой статье описывается решение проблемы, при которой отображается сообщение об ошибке HTTP 500.19 в веб-приложении в IIS 7.0 и более поздних версиях.
Оригинальная версия продукта: службы IIS 7.0 и более поздних версий
Оригинальный номер КБ: 942055
Чтобы устранить эту ошибку, ознакомьтесь со следующими разделами для получения соответствующих сведений о коде ошибки.
Код HRESULT 0x8007000d
Сообщение об ошибке:
Ошибка сервера в приложении «имя приложения»
Ошибка HTTP 500.19 — внутренняя ошибка сервера
HRESULT: 0x8007000d
Описание HRESULT:
Запрашиваемая страница недоступна из-за неверной конфигурации данных для этой страницы.
Эта проблема возникает из-за того, что файл ApplicationHost.config или Web.config содержит поврежденный или неопознанный XML-элемент. IIS не может определить XML-элементы модулей, которые не были установлены. Например, модуль переопределения URL-адресов для IIS.
Используйте один из следующих способов:
- Удалите поврежденный XML-элемент из файла ApplicationHost.config или Web.config.
- Проверьте неопознанные XML-элементы и установите соответствующие модули IIS.
Код HRESULT 0x80070021
Сообщение об ошибке:
Ошибка сервера в приложении «имя приложения»
Ошибка HTTP 500.19 — внутренняя ошибка сервера
HRESULT: 0x80070021
Описание HRESULT:
Запрашиваемая страница недоступна из-за неверной конфигурации данных для этой страницы.
Эта проблема может возникать, когда указанная часть файла конфигурации IIS блокируется на более высоком уровне конфигурации.
Разблокируйте указанный раздел или не используйте его на более высоком уровне. Дополнительные сведения о блокировке конфигурации см. в разделе Использование блокировки в конфигурации IIS 7.0.
Код HRESULT 0x80070005
Сообщение об ошибке:
Ошибка сервера в приложении «имя приложения»
Ошибка HTTP 500.19 — внутренняя ошибка сервера
HRESULT: 0x80070005
Описание HRESULT:
Запрашиваемая страница недоступна из-за неверной конфигурации данных для этой страницы.
Эта проблема может возникать по одной из следующих причин:
- IIS используется на компьютере под управлением Windows. Кроме того, настройте веб-сайт для использования сквозной проверки подлинности UNC для доступа к удаленному серверу общего доступа UNC.
- У группы IIS_IUSRS нет необходимых разрешений для файла ApplicationHost.config, Web.config или виртуальных каталогов/каталогов приложений IIS.
Используйте один из следующих способов:
- Не задавайте в настройках веб-сайта использование сквозной проверки подлинности UNC для доступа к удаленному серверу общего доступа UNC. Вместо этого укажите учетную запись пользователя с надлежащими разрешениями для доступа к удаленному ресурсу UNC.
- Предоставьте группе IIS_IUSRS разрешение на чтение файла ApplicationHost.config или Web.config. Для этого выполните следующие действия:
- В проводнике Windows найдите папку, содержащую файл ApplicationHost.config, связанный с веб-сайтом, либо виртуальные каталоги или каталоги приложений, содержащие связанный с веб-сайтом файл Web.config.
Примечание. Файл Web.config может не находиться в виртуальных каталогах или каталогах приложений в IIS. Даже в такой ситуации необходимо выполнить следующие действия.
Примечание. <Computername> — это заполнитель для имени компьютера.
Примечание. Удостоверьтесь, что свойства папки наследуются файлами ApplicationHost.config и Web.config, чтобы у IIS_IUSRS было разрешение на чтение таких файлов.
Код HRESULT 0x800700b7
Сообщение об ошибке:
Ошибка сервера в приложении «имя приложения»
Ошибка HTTP 500.19 — внутренняя ошибка сервера
HRESULT: 0x800700b7
Описание HResult
Запрашиваемая страница недоступна из-за неверной конфигурации данных для этой страницы.
Эта проблема может возникать при наличии повторяющейся записи для указанного раздела конфигурации, заданного на более высоком уровне в иерархии конфигурации (например, файл ApplicationHost.config или Web.config на родительском веб-сайте или в папке). В сообщении об ошибке указано расположение повторяющихся записей.
Изучите указанный файл конфигурации и сравните его с родительским файлом ApplicationHost.config или Web.config, чтобы проверить наличие повторяющихся записей, предполагаемых в сообщении об ошибке. Удалите дублирующую запись или сделайте ее уникальной. Например, эта проблема может возникать из-за того, что в файле ApplicationHost.config содержится повторяющаяся запись для следующего кода:
Чтобы решить эту проблему, удалите в файле ApplicationHost.config повторяющуюся запись для правила авторизации. Для этого выполните следующие действия:
-
Нажмите кнопку Пуск, введите Блокнот в поле Начать поиск, затем щелкните правой кнопкой мыши Блокнот и выберите Запуск от имени администратора.
Примечание. Если система запросит пароль администратора или подтверждение, введите пароль или нажмите кнопку Продолжить.
Код HRESULT 0x8007007e
Сообщение об ошибке:
Ошибка сервера в приложении «имя приложения»
Ошибка HTTP 500.19 — внутренняя ошибка сервера
HRESULT: 0x8007007e
Описание HResult
Запрашиваемая страница недоступна из-за неверной конфигурации данных для этой страницы.
Эта проблема возникает в том случае, если файл ApplicationHost.config или Web.config ссылается на модуль или библиотеку DLL, которые являются недопустимыми или не существуют.
В файле ApplicationHost.config или Web.config найдите недопустимую ссылку на модуль или библиотеку DLL и исправьте ее. Чтобы определить, какая ссылка на модуль неверная, включите функцию «Трассировка невыполненных запросов» и воспроизведите проблему.
Код HRESULT 0x800700c1
Сообщение об ошибке:
Ошибка сервера в приложении «имя приложения»
Ошибка HTTP 500.19 — внутренняя ошибка сервера
HRESULT: 0x800700c1
Описание HRESULT:
Запрашиваемая страница недоступна из-за неверной конфигурации данных для этой страницы.
Эта проблема может возникать, если разрядность указанного модуля отличается от разрядности пула приложений, где он размещен. Например, если вы пытаетесь загрузить 32-разрядный компонент в 64-разрядный пул приложений. Подобная проблема может также наблюдаться при повреждении указанного модуля.
Убедитесь, что разрядность указанного модуля такая же, как и у пула размещенных приложений. Кроме того, убедитесь, что модуль не поврежден.
Код HRESULT 0x8007010b
Сообщение об ошибке:
Ошибка сервера в приложении «имя приложения»
Ошибка HTTP 500.19 — внутренняя ошибка сервера
HRESULT: 0x8007010b
Описание HRESULT:
Запрашиваемая страница недоступна из-за неверной конфигурации данных для этой страницы.
Эта проблема может возникать, если указанный каталог содержимого недоступен.
- Убедитесь, что путь к файлу существует.
- Убедитесь, что путь к файлу указан правильно.
- Убедитесь, что путь к файлу имеет правильный набор разрешений на уровне файлов.
- Убедитесь, что путь к файлу указывает на допустимый тип файловой системы.
Если вам точно не известен путь к файлу, определите его с помощью монитора процессов или трассировки невыполненных запросов.
Код HRESULT 0x8007052e
Сообщение об ошибке:
Ошибка сервера в приложении «имя приложения»
Ошибка HTTP 500.19 — внутренняя ошибка сервера
HRESULT: 0x8007052e
Описание HRESULT:
Запрашиваемая страница недоступна из-за неверной конфигурации данных для этой страницы.
У удостоверения процесса по умолчанию в IIS недостаточно разрешений для открытия файла Web.config на удаленном общем ресурсе.
Убедитесь, что учетная запись удостоверения пула приложений этого веб-приложения имеет достаточно разрешений для открытия файла Web.config.
Код HRESULT 0x80070003
Сообщение об ошибке:
Ошибка сервера в приложении «имя приложения»
Ошибка HTTP 500.19 — внутренняя ошибка сервера
HRESULT: 0x80070003
Описание HRESULT:
Не удается прочитать файл конфигурации.
Эта ошибка вызвана отсутствием разрешения или физическим путем, который не соответствует пути для виртуального каталога. Например, в физическом корневом пути веб-приложения нет Web.config.
- Убедитесь, что путь Web.config существует и имеет правильный набор разрешений.
- Выполните сбор журналов монитора процессов, чтобы получить дополнительные сведения об ошибке.
Устраните проблему с поврежденным файлом конфигурации IIS при обновлении Windows
В соответствии с общим правилом безопасности для всех файлов конфигурации (не ограниченные IIS) должны быть созданы резервные копии перед установкой какого-либо обновления. Если вы используете виртуальные машины, сделайте снимок виртуальной машины перед ее обновлением. Этот совет применим не только к обновлениям Windows.
Обратная связь
Были ли сведения на этой странице полезными?
Клуб студентов «Технарь». Уникальный сайт с дипломами и курсовыми для технарей.
6. Общесистемные и локальные проектные решения разрабатываются на этапе:
7. В качестве действующего лица (актера) на диаграммах вариантов использования не может выступать…
8. Проектирование информационной системы, когда происходит адаптация проектных решений путем переработки соответствующих компонентов – это …
9. На диаграмме состояний переход от одного состояния к другому вызывает…
10. Жизненный цикл по по методологии rad состоит из:
· анализа и планирования требований, проектирования, построения, внедрения
· сбора сведения и опроса пользователей, планирования, построения модели, разработки и построения
· согласования, уведомления, приведения и построения
· моделирования, проектирования, построения, согласования
· использующий условный синтаксис метод разработки реляционных баз данных
· вариация IDEF1, основанная на использовании концептуальной схемы
· методология проектирования реляционных баз данных
· методология для построения концептуальной схемы логической структуры реляционной базы данных, которая была бы независимой от программной платформы её конечной реализации
12. Результатом предпроектной стадии является … мн
· сбор материалов для обследования
· технико-экономическое обоснование проекта
13. Прототип – это …
· разрабатываемый программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО
· действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО
· модель информационной системы, построенная на начальных «витках спирали»
· окончательный вариант разрабатываемого ПО
14. В разработке языка uml принимал участие …
15. В allfusion process modeler диаграмма дерева узлов показывает …
· то же, что диаграмма IDEF0
· то же, что и диаграмма IDEF3
· альтернативную точку зрения на бизнес-процессы
16. Государственный стандарт гост 19.102-77 устанавливает следующие стадии разработки программной документации:
· Техническое задание, Эскизный проект, Технический проект, Рабочий проект, Внедрение
· Технико-экономическое обоснование, Техническое задание, Эскизный проект, Техно-рабочий проект, Внедрение
· Техническое задание, Эскизный проект, Технический проект, Рабочий проект, Акт о внедрение, Акт о сдачи в эксплуатацию
· Технико-экономическое обоснование, Техническое задание, Эскизный проект, Технический проект, Рабочий проект, Внедрение
17. Основные стандарты жизненного цикла информационных систем:
· ГОСТ Р ИСО/ИЭК 12207:1995; Oracle CDM; Rational Rose Process; Microsoft Solution Framework; Extreme Programming
· ГОСТ 34.601-90; РД IDEF-2000; MIL-STD-188
· Семейство стандартов IDEF
· модернизация системы начинается сразу после внедрения
· техническому проектированию предшествует эскизный проект
· на этапе внедрения заканчивается жизненный цикл ИС
· разработка технического задания начинается после исследования предметной области
19. Неверно, что техническое задание включает …
· состав и содержание работ по созданию системы
· характеристику объекта автоматизации
· требования к системе
20. Case-средства наиболее необходимы …
· на начальных этапах анализа и проектирования ИС
· для генерации кода программы
· в процессе внедрения системы в опытную эксплуатацию
· для разработки небольших локальных ИС
21. В uml не существует стереотипа (типа класса)…
22. На диаграмме dfd вход в систему и/или выход из системы изображается с помощью…
23. Верным утверждением, является «…» мн
· каждая работа на функциональной диаграмме обязательно должна иметь хотя бы одну стрелку управления
· на функциональной диаграмме по усмотрению разработчиков могут не отображаться механизмы
· каждая работа на функциональной диаграмме обязательно должна иметь хотя бы одну стрелку входа
· каждая работа на функциональной диаграмме обязательно должна иметь несколько стрелок выхода
24. Переподготовка и реорганизация кадров в связи с внедрением новой ис фиксируется в:
· Акте о проведение опытного внедрения
· Приказе о начале промышленного внедрения
· Акте о готовности объекта к внедрению
· Программе проведения испытаний
25. Неверно, что у блока работы на диаграмме idef0…
· по усмотрению разработчиком можно не указывать механизмы
· всегда должна быть стрелка входа
· всегда должна быть стрелка выхода
· всегда должна быть стрелка управления
26. Класс объектов – это совокупность объектов, …
· использующих одинаковые методы
· отображенных на одной диаграмме
· относящихся к одной предметной области
· имеющих общий набор свойств и характеризующихся одинаковым поведением
27. Для idef1x неверно, что…
· логический уровень отражает абстрактный взгляд на данные
· и на логическом, и на физическом уровне поддерживается связь «многие-ко-многим»
· на логическом уровне используются понятия сущность и атрибут
· одному логическому уровню может соответствовать несколько физических уровней
28. Для модели as-is …
· разрабатывается информационная система
· составляется проектная документация
· строится несколько моделей TO-BE
29. Множество подобных индивидуальных объектов, называемых экземплярами – это…
30. Каноническое проектирование …
· это технология, в которой основной упор делается на начальные этапы проектирования
· поддерживается большинством CASE-средств
· это технология, в основе которой лежит спиральная модель жизненного цикла
· это ручная технология индивидуального (оригинального) проектирования
31. По степени интегрированности case-средства различают:
· tools, toolkit, workbench
· функицонально-ориентированные, объектно-ориентированные и смешанные
· CASE-средства, поддерживающие какой-либо один этапов жизненного цикла ИС и CASE-средства, поддерживающие несколько этапов жизненного цикла ИС
· локальные и распределенные
32. Потоки работ во взаимосвязанных вариантах использования отображаются на диаграмме …
33. Основные стандарты жизненного цикла информационных систем:
· ГОСТ Р ИСО/ИЭК 12207:1995; Oracle CDM; Rational Rose Process; Microsoft Solution Framework; Extreme Programming
· ГОСТ 34.601-90; РД IDEF-2000; MIL-STD-188
· Семейство стандартов IDEF
34. Жизненный цикл информационной системы начинается с момента …
· установки на пользовательские места
· создания и утверждения модели разрабатываемой информационной системы
· принятия решения о создании информационной системы
35. Значения, которые устанавливаются для определения вида и поведения объекта – это…
36. На диаграмме классов объектов при описании конкретного класса указывают имена …
· представление сценария бизнес-процесса
· средство для удобного описания рабочих процессов для которых важно отразить логическую последовательность выполнения процедур
· методология документирования процессов, происходящих в системе
· стандарт для описания последовательностей и логики взаимодействия операций и событий в анализируемой системе
38. Целью построения модели as-is является …
· определение требований к будущей информационной системе
· реинжиниринг бизнес-процессов предприятия
· адаптация разрабатываемой ИС к условиям деятельности организации
· выявление слабых и уязвимых мест деятельности организации
39. Требования к системе фиксируется в диаграммах…
40. Цель реинжиниринга бизнес-процессов …
· системная реорганизация информационных потоков, перераспределение ресурсов и сокращение сроков выполнения заказов, повышение качества обслуживания клиентов в условиях новой информационной системы
· перераспределение ресурсов предприятия с целью повышения прибыли и увеличения доли на рыке
· системная реорганизация материальных, финансовых и информационных потоков, направленных на упрощение организационной структуры, перераспределение и минимизацию использования различных ресурсов, сокращение сроков реализации потребностей клиентов, повышение качества их обслуживания
· перераспределение ресурсов (трудовых, финансовых и др.) и минимизация затрат, направленный на оптимизацию организационной структуры предприятия, повышение эффективности его функционирования при внедрении новой информационной системы
41. Методология rad применима для … мн
· информационных киосков метрополитена
· банковских информационных систем
· сложных расчетных программ, операционных систем и других программ большого объема
· экономических информационных систем
42. Проектирование информационной системы, когда происходит адаптация проектных решений путем переработки соответствующих компонентов – это …
43. … является функционально-ориентированным case-средством
· AllFusion Modeling Suite
44. Прототип – это …
· разрабатываемый программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО
· действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО
· модель информационной системы, построенная на начальных «витках спирали»
· окончательный вариант разрабатываемого ПО
45. На диаграммах потоков данных отображается … мн
46. Принцип, в соответствии с которым на разработку системы затрачивается меньше финансовых средств, при условии получения высокой эффективности, называется …
47. В техническое задание включают …
· требования к системе
· характеристику объекта автоматизации
· состав и содержание работ по созданию системы
48. Средства проектирования должны… множественный
· Зависеть от конкретной ОС и СУБД
· Охватывать начальные этапы жизненного цикла ИС
· Охватывать весь жизненный цикл ИС
Комментарии: Сборник ответов на тест Синергия
Ответы выделены в документе
48 вопросов 90 + баллов
Размер файла: 2,6 Мбайт
Фаил: (.zip)
——————-
Обратите внимание , что преподаватели часто переставляют варианты и меняют исходные данные!
Если вы хотите, чтобы работа точно соответствовала, смотрите исходные данные. Если их нет, обратитесь к продавцу или к нам в тех. поддержку.
Имейте ввиду, что согласно гарантии возврата средств, мы не возвращаем деньги если вариант окажется не тот.
——————-
Скачано: 27 Сейчас качают: 1 Коментариев: 0
1.1. Основы проектирования баз данных
Разработанная функциональная модель системы отвечает на вопросы «Что должна делать система?» и «За счет каких действий может быть достигнут требуемый результат?». Эта модель также позволяет концептуально определить наборы данных, используемых в системе.
В то же время она не отвечает на вопрос «Каким образом организованы данные в системе?». Для ответа на него необходимо построить информационную модель (запроектировать БД).
Традиционно процедуру проектирования базы данных разбивают на три этапа, каждый из которых завершается созданием соответствующей информационной модели.
Этап 1-й. Концептуальное проектирование – создание представления (схемы, модели) БД, включающего определение важнейших сущностей (таблиц) и связей между ними, но не зависящего от модели БД (иерархической, сетевой, реляционной и т. д.) и физической реализации (целевой СУБД).
Этап 2-й. Логическое проектирование – развитие концептуального представления БД с учетом принимаемой модели (иерархической, сетевой, реляционной и т.д.).
Этап 3-й. Физическое проектирование – развитие логической модели БД с учетом выбранной целевой СУБД.
Концептуальное и логическое проектирование вместе называют также инфологическим или семантическим проектированием.
В настоящее время для проектирования БД активно используются CASE-средства, в основном ориентированные на использование ERD (Entity – Relationship Diagrams, диаграммы «сущность–связь»). С их помощью определяются важные для предметной области объекты (сущности), отношения друг с другом (связи) и их свойства (атрибуты). Следует отметить, что средства проектирования ERD в основном ориентированы на реляционные базы данных (РБД), и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы проектирования.
ERD были впервые предложены П. Ченом в 1976 г. Основные элементы ERD перечислены ниже .
Сущность (таблица, в РБД – отношение) – реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению. Если выражаться точнее, то это не объект, а набор объектов (класс) с одинаковыми свойствами. Примеры сущностей: работник, деталь, ведомость, результаты сдачи экзамена и т. д.
Экземпляр сущности (запись, строка, в РБД – кортеж) – уникально идентифицируемый объект.
Связь – некоторая ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Примерами связей могут являться родственные отношения «отец–сын», производственные – «начальник-подчиненный» или произвольные – «иметь в собственности», «обладать свойством».
Атрибут (столбец, поле) – свойство сущности или связи.
Большинство современных CASE-средств моделирования данных, как правило, поддерживает несколько графических нотаций построения информационных моделей. В частности система ERwin фирмы Computer Associates поддерживает две нотации: IDEF1X и IE (англ. Information Engineering – информационное проектирование). Данные нотации являются взаимно-однозначными, т. е. переход от одной нотации к другой и обратно выполняется без потери качества модели. Отличие между ними заключается лишь в форме отображения элементов модели.
При использовании любого CASE-средства вначале строится логическая модель БД в виде диаграммы с указанием сущностей и связей между ними. Логической моделью называется универсальное представление структуры данных, независимое от конечной реализации базы данных и аппаратной платформы. На основании полученной логической модели переходят к физической модели данных. Физическая модель представляет собой диаграмму, содержащую всю необходимую информацию для генерации БД для конкретной СУБД или даже конкретной версии СУБД. Если в логической модели не имеет значения, какие идентификаторы носят таблицы и атрибуты, тип данных атрибутов и т. д., то в физической модели должно быть полное описание БД в соответствии с принятым в ней синтаксисом, с указанием типов атрибутов, триггеров, хранимых процедур и т. д. По одной и той же логической модели можно создать несколько физических. Например, ERwin 4.0 позволяет на основании логической модели сформировать физические более, чем для 20 популярных СУБД (ORACLE, Informix, DB2, MS SQL Server, Access, Foxpro, Paradox и т. д.). На основании физической модели можно сгенерировать либо саму БД или DDL-скрипт 1 , который, в свою очередь, может быть использован для генерации БД.
Перечисленный выше порядок действий называется прямое проектирование БД (Forward Engineering DB). CASE-средства позволяют выполнять также обратное проектирование БД (Reverse Engineering DB), т.е. на основании системного каталога БД или DDL-скрипта построить физическую и, далее, логическую модель данных.
Кроме режимов прямого и обратного проектирования, CASE-средства обычно поддерживают синхронизацию между моделью и системным каталогом БД, т. е. при изменении модели они могут автоматически внести все необходимые изменения в существующую БД и наоборот.
Развитые CASE-средства обладают также встроенной подсистемой поиска и исправления ошибок в модели. Особенно полезна эта функция при проектировании больших БД, содержащих десятки или сотни таблиц, а также при обратном проектировании.
Следует отметить, что современные СУБД обладают своими встроенными средствами визуального моделирования данных. Некоторые из них даже поддерживают классические нотации ERD. Недостатками такого моделирования является построение только физической модели данных и невозможность быстрого перехода на другую СУБД, если такое решение принято. Достоинством этого подхода является более полное использование потенциала СУБД, ведь разработчики СУБД лучше других знают ее особенности и возможности.
Далее рассматривается процедура прямого проектирования с использованием методологии IDEF1X. Методология IDEF1 была разработана Т. Рэмеем. В настоящее время на основе IDEF1 создана ее новая версия – методология IDEF1X, которая в 1981 г. принята ICAM в качестве федерального стандарта США.
1 Data Definition Language – язык определения данных, подмножество языка SQL.
1.2. Концептуальное проектирование с использованием методологии IDEF1X
Цель концептуального проектирования – создание концептуальной модели данных на основе представлений о предметной области каждого отдельного типа пользователей. Концептуальная модель представляет собой описание основных сущностей (таблиц) и связей между ними без учета принятой модели БД и синтаксиса целевой СУБД. Часто на такой модели отображаются только имена сущностей (таблиц) без указания их атрибутов. Представление пользователя включает в себя данные, необходимые конкретному пользователю для принятия решений или выполнения некоторого задания.
Ниже рассматривается последовательность шагов при концептуальном проектировании.
1. Выделение сущностей.
Первый шаг в построении концептуальной модели данных состоит в определении основных объектов (сущностей), которые могут интересовать пользователя и, следовательно, должны храниться в БД. При наличии функциональной модели IDEF0 прообразами таких объектов являются входы, управления и выходы. Еще лучше для этих целей использовать DFD. Прообразами объектов в этом случае будут накопители данных. Как было отмечено выше, накопитель данных является совокупностью таблиц (набором объектов) или непосредственно таблицей (объектом). Для более детального определения набора основных объектов необходимо также проанализировать потоки данных и весь методический материал, требуемый для решения задачи. Например, для задачи определения допускаемых скоростей основными объектами (наборами объектов) являются: нормативно-справочная информация, информация об участках дороги, задания на расчет, ведомости допускаемых скоростей и т. д. В ходе анализа и проектирования информационной модели наборы объектов должны быть детализированы. Например, составной объект «информация об участках дороги» с учетом специфики решаемой задачи требует разбиения на отдельные составляющие: участки, пути, раздельные пункты, километраж, план, верхнее строение пути и т. д.
Возможные трудности в определении объектов связаны с использованием постановщиками задачи:
· примеров и аналогий при описании объектов (например, вместо обобщающего понятия «работник» они могут упоминать его функции или занимаемую должность: «руководитель», «ответственный», «контролер», «заместитель»);
· синонимов (например, «допускаемая скорость» и «установленная скорость», «разработка» и «проект», «барьерное место» и «ограничение скорости»);
· омонимов (например, «программа» может обозначать компьютерную программу, план предстоящей работы или программу телепередач).
Далеко не всегда очевидно то, чем является определенный объект – сущностью, связью или атрибутом. Например, как следует классифицировать «семейный брак»? На практике это понятие можно вполне обоснованно отнести к любой из упомянутых категорий. Анализ является субъективным процессом, поэтому различные разработчики могут создавать разные, но вполне допустимые интерпретации одного и того же факта. Выбор варианта в значительной степени зависит от здравого смысла и опыта проектировщика.
Каждая сущность должна обладать некоторыми свойствами:
· должна иметь уникальное имя, и к одному и тому же имени должна всегда применяться одна и та же интерпретация;
· обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;
· обладать одним или несколькими атрибутами (первичным ключом), которые однозначно идентифицируют каждый экземпляр сущности, т. е. делают уникальной каждую строку таблицы;
· может обладать любым количеством связей с другими сущностями.
В графической нотации IDEF1X для отображения сущности используются обозначения, изображенные на рис. 7.1.
Рис. 7.1. Сущности
Сущность в методологии IDEF1X является независимой (сильной, родительской, доминантной, владельцем), если сущность не зависит от существования другой сущности (другими словами, каждый экземпляр сущности может быть однозначно идентифицирован без определения его связей с другими сущностями, или уникальность экземпляра определяется только собственными атрибутами). Сущность называется зависимой (слабой, дочерней, подчиненной), если ее существование зависит от существования других сущностей. Терминология «родительская» – «дочерняя» и «владелец» – «подчиненный» также может использоваться в отношении двух зависимых сущностей, если экземпляры одной из них (дочерней, подчиненной) могут быть однозначно определены с использованием экземпляров другой (родительской, владельца), несмотря на то, что вторая сущность в свою очередь зависит от третьей сущности.
2. Определение атрибутов.
Как правило, атрибуты указываются только для сущностей. Если у связи имеются атрибуты, то это указывает на тот факт, что связь является сущностью. Самый простой способ определения атрибутов – после идентификации сущности или связи, задать себе вопрос «Какую информацию требуется хранить о …?». Существенно помочь в определении атрибутов могут различные бумажные и электронные формы и документы, используемые в организации при решении задачи. Это могут быть формы, содержащие как исходную информацию (например, «Ведомость возвышений наружного рельса в кривых»), так и результаты обработки данных (например, «Форма № 1»).
Выявленные атрибуты могут быть следующих видов:
· простой (атомарный, неделимый) – состоит из одного компонента с независимым существованием (например, «должность работника», «зарплата», «норма непогашенного ускорения», «радиус кривой» и т. д.);
· составной (псевдоатомарный) – состоит из нескольких компонентов (например, «ФИО», «адрес», и т. д.). Степень атомарности атрибутов, закладываемая в модель, определяется разработчиком. Если от системы не требуется выборки всех клиентов с фамилией Иванов или проживающих на улице Комсомольской, то составные атрибуты можно не разбивать на атомарные;
· однозначный – содержит только одно значение для одного экземпляра сущности (например, у кривой в плане может быть только одно значение радиуса, угла поворота, возвышения наружного рельса и т. д.);
· многозначный – содержит несколько значений (например, у одного отделения компании может быть несколько контактных телефонов);
· производный (вычисляемый) – значение атрибута может быть определено по значениям других атрибутов (например, «возраст» может быть определен по «дате рождения» и текущей дате, установленной на компьютере);
· ключевой – служит для уникальной идентификации экземпляра сущности (входит в состав первичного ключа);
· неключевой (описательный) – не входит в первичный ключ;
· обязательный – при вводе нового экземпляра в сущность или редактировании обязательно указывается допустимое значение атрибута, т. е. оно после редактирования не может быть неопределенным (NOT NULL).
После определения атрибутов задаются их домены (области допустимых значений), например:
· наименование участка – набор из букв русского алфавита длиной не более 60 символов;
· поворот кривой – допустимые значения «Л» (влево) и «П» (вправо);
· радиус кривой – положительное число не более 4 цифр.
Задание доменов определяет набор допустимых значений для атрибута (нескольких атрибутов), а также тип, размер и формат атрибута (атрибутов).
На основании выделенного множества атрибутов для сущности определяется набор ключей. Ключ – один или несколько атрибутов сущности, служащих для однозначной идентификации ее экземпляров или для их быстрого поиска. Выделяют следующие типы ключей:
· суперключ (superkey) – атрибут или множество атрибутов, которое единственным образом идентифицирует экземпляр сущности. Суперключ может содержать «лишние» атрибуты, которые необязательны для уникальной идентификации экземпляра. При правильном проектировании структуры БД суперключом в каждой сущности (таблице) будет являться полный набор ее атрибутов;
· потенциальный ключ (potential key) – суперключ, который не содержит подмножества, также являющегося суперключом данной сущности, т. е. суперключ, содержащий минимально необходимый набор атрибутов, единственным образом идентифицирующих экземпляр сущности. Сущность может иметь несколько потенциальных ключей. Если ключ состоит из нескольких атрибутов, то он называется составным ключом. Среди всего множества потенциальных ключей для однозначной идентификации экземпляров выбирают один, так называемый первичный ключ, используемый в дальнейшем для установления связей с другими сущностями;
· первичный ключ (primary key) – потенциальный ключ, который выбран для уникальной идентификации экземпляров внутри сущности;
· альтернативные ключи (alternative key) – потенциальные ключи, которые не выбраны в качестве первичного ключа.
Если некий атрибут (набор атрибутов) присутствует в нескольких сущностях, то его наличие обычно отражает наличие связи между экземплярами этих сущностей. В каждой связи одна сущность выступает как родительская, а другая – в роли дочерней. Это означает, что один экземпляр родительской сущности может быть связан с несколькими экземплярами дочерней. Для поддержки этих связей обе сущности должны содержать наборы атрибутов, по которым они связаны. В родительской сущности это первичный ключ. В дочерней сущности для моделирования связи должен присутствовать набор атрибутов, соответствующий первичному ключу родительской. Однако здесь этот набор атрибутов уже является вторичным ключом. Данный набор атрибутов в дочерней сущности принято называть внешним ключом (foreign key).
Рассмотрим пример. Пусть имеется таблица, содержащая сведения о студенте, со следующими столбцами:
· номер пенсионного страхового свидетельства (НПСС);
· дата выдачи паспорта;
· организация, выдавшая паспорт.
Для каждого экземпляра (записи) в качестве суперключа может быть выбран весь набор атрибутов. Потенциальными ключами (уникальными идентификаторами) могут быть:
· номер пенсионного страхового свидетельства;
В качестве уникального идентификатора можно было бы выбрать совокупность атрибутов «Фамилия»+«Имя»+«Отчество», если вероятность учебы в вузе двух полных тезок была бы равна нулю.
Если в сущности нет ни одной комбинации атрибутов, подходящей на роль потенциального ключа, то в сущность добавляют отдельный атрибут – суррогатный ключ (искусственный ключ, surrogate key). Как правило, тип такого атрибута выбирают символьный или числовой. В некоторых СУБД имеются встроенные средства генерации и поддержания значений суррогатных ключей (например, MS Access).Также стоит отметить, что некоторые разработчики вместо поиска потенциальных ключей и выбора из них первичного в каждую сущность добавляют искусственный атрибут, который в дальнейшем и используют в качестве первичного ключа.
Если потенциальных ключей несколько, то для выбора первичного ключа рекомендуется придерживаться следующих правил:
· количество атрибутов, входящих в ключ, должно быть минимальным (желательно, чтобы ключ был атомарным, т. е. состоял из одного атрибута);
· размер ключа в байтах должен быть как можно короче;
· тип домена ключа – числовой. При выборе символьных атрибутов в ключ часто возникают проблемы с вводом ошибочных значений (путают регистр букв; добавляют лишние пробелы; используют буквы, пишущиеся на разных языках одинаково). В числовых атрибутах вероятность ошибки при вводе значения меньше;
· вероятность изменения значений ключа была наименьшей (например, «Номер пенсионного страхового свидетельства» более постоянный параметр, чем «ИНН» или «Номер паспорта»);
· с ключом проще всего работать пользователям (например, «Номер пенсионного страхового свидетельства» – это набор из 11 цифр, а «Номер паспорта» зависит от его вида: гражданина СССР, гражданина РФ или зарубежный).
В нотации IDEF1X атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой. Предварительная идентификация атрибутов на примере двух сущностей показана на рис. 7.2.
Рис. 7.2. Сущности
У независимой сущности «Участки» в качестве первичного ключа назначен суррогатный ключ, у зависимой сущности «План» – первичный ключ составной, состоящий из пяти атрибутов.
3. Определение связей.
Наиболее характерными типами связей между сущностями являются:
· связи типа «часть–целое», определяемые обычно глаголами «состоит из», «включает» и т.п.;
· классифицирующие связи (например, «тип – подтип», «множество – элемент», «общее – частное» и т. п.);
· производственные связи (например, «начальник–подчиненный»);
· функциональные связи, определяемые обычно глаголами «производит», «влияет», «зависит от», «вычисляется по» и т. п.
Среди них выделяются только те связи, которые необходимы для удовлетворения требований к разработке БД.
Связь характеризуется следующим набором параметров:
· именем – указывается в виде глагола и определяет семантику (смысловую подоплеку) связи;
· кратностью (кардинальность, мощность): один-к-одному (1:1), один-ко-многим (1:N) и многие-ко-многим (N:M, N = M или N <> M). Кратность показывает, какое количество экземпляров одной сущности определяется экземпляром другой. Например, на одном участке (описывается строкой таблицы «Участки») может быть один, два и более путей (каждый путь описывается отдельной строкой в таблице «Пути»). В данном случае связь 1:N. Другой пример: один путь проходит через несколько раздельных пунктов и через один раздельный пункт может проходить несколько путей – cвязь N:M;
· типом: идентифицирующая (атрибуты одной сущности, называемые внешним ключом, входят в состав дочерней и служат для идентификации ее экземпляров, т.е. входят в ее первичный ключ) и неидентифицирующая (внешний ключ имеется в дочерней сущности, но не входит в состав первичного ключа);
· обязательностью: обязательная (при вводе нового экземпляра в дочернюю сущность заполнение атрибутов внешнего ключа обязательно и для введенных значений должен существовать экземпляр в родительской сущности) и необязательная (заполнение атрибутов внешнего ключа в экземпляре дочерней сущности необязательно или введенным значениям не соответствует экземпляр в родительской сущности);
· степенью участия – количеством сущностей, участвующих в связи. В основном между сущностями существуют бинарные связи, т. е. ассоциации, связывающие две сущности (степень участия равна 2). Например, «Участок» состоит из «Путей». В то же время по степени участия возможны следующие типы связей:
o унарная (рекурсивная) – сущность может быть связана сама с собой. Например, в таблице «Работники» могут быть записи и по подчиненным, и по их начальникам. Тогда возможна связь «начальник» – «подчиненный», определенная на одной таблице;
o тернарная – связывает три сущности. Например, «Студент» на «Сессии» получил «Оценку по дисциплине»;
o кватернарная и т.д.
В методологии IDEF1X степень участия может быть только унарной или бинарной. Связи большей степени приводятся к бинарному виду.
Внешний вид связи на диаграммах IDEF1X указывает на ее мощность, тип и обязательность (табл. 7.1).