12
.pdf
• |
одна |
таблица |
на |
класс; |
• |
одна |
таблица |
на |
суперкласс; |
• |
одна |
таблица |
на |
иерархию. |
Впервомслучаедлякаждогоизклассовсоздаетсяотдельнтаблицая, междукоторымизатем устанавливаютсянеобходимыесвязи. Вовторомслучаесоздаетсятаблицадлясуперкласса, затемвкаждуютаблицуподклассоввключаютсястолбцыдлякаждогоизатрибутов суперкласса. Втретьем–создаетсяединаятаблица, содержащаяатрибутыкаксуперкласса, такивсехподклассов( рис. 12.13 ).Приэтомдлявыделенияисходныхтаблицподклассов результирующуютаблицудобавляетсяодинилиболеедополнительныхстолбцов(нарисунке показанкурсивом).
Рис. 12.13. Преобразованиеиерархиивтаблицу
Разработкапроектаб зыданныхосуществляетиспользованияспециальногомUMLпрофиля(Profile for DatabaseкоторыйDesign),включаетследующиеосновныекомпоненты диаграмм:
• |
таблица– набор |
записей |
базы |
данных |
по |
определенномуобъекту; |
|
|
|
|||||
•столбец–элементтаблицы, содержащийзначенияодногоизатрибутовтаблицы; |
|
|
|
|
|
|||||||||
• |
первичный ключ ( |
РК ) – |
атрибут, однозначноидентифицирующийстроку таблицы; |
|||||||||||
• |
внешний ключ (FK) –один |
|
или |
группа |
атрибутов одной |
таблицы, |
которые могут |
|||||||
|
использоватьсякакпервичныйключдругойтаблицы; |
|
|
|
|
|
|
|
||||||
• |
обязательнаясвязь – связь |
между |
двумя |
таблицами, |
при |
которой |
дочерняя таблица |
|||||||
|
существуеттольковместеродительской; |
|
|
|
|
|
|
|
|
|
||||
• |
необязательнаясвязь – связь |
между |
таблицами, при |
которой каждая из таблиц мож |
||||||||||
|
существоватьнезависимоотдругой; |
|
|
|
|
|
|
|
|
|
|
|||
• |
представление– виртуальнаятаблица, |
которая |
обладает всеми свойствами обычной |
|||||||||||
|
таблицы, нонехранитсяпостоянновбазеданных; |
|
|
|
|
|
|
|
||||||
• |
хранимая процедура– функция обработки данных, выполняемаяна сервере; |
|||||||||||||
•домен–множестводопустимыхзначенийдлястолбцаблицы. |
|
|
|
|
|
|
|
|||||||
На рис. 12.14 представленфрагментмоделибазыданных—дветаблицы, соответствующие |
|
|
|
|||||||||||
|
|
|
, рис. 12.6 |
)и " минимальный набор данных " (рис. 12.8 ).Связь |
||||||||||
классам" пациент " (рис. 12.3 |
||||||||||||||
|
|
|
|
|
|
|
|
|||||||
междунимиобязательная, поскольку" |
|
|
минимальный набор данных "неможетсуществовать |
|||||||||||
без" |
пациента ". |
|
|
|
|
|
|
|
|
|
|
|
|
|
Рис. 12.14. Фрагментмоделибазыданных
Надиаграммахуказываютсядополнительныехарактеристаблицикистолбцов:
• |
ограничения– определяютдопустимыезначения данных в столбце или операции над |
|
данными(ключ(PK,FK)ограничение– , определяющеетипключаиегостолбец; |
|
проверка(Check)ограничение– , определяющееправилок нтроляданных;уникальность |
|
(Unique)ограничение– , определяющее, чтовстолбцесодержатсянеповторяющиеся |
|
данные); |
• |
триггер– программа, выполняющаяпри определенныхусловиях предписанныедействия |
сбазойданных;
•тип данных и пр .
Результатомэтапаявляетсядетальноеописаниепроектаб зыданныхиприложенсистемый.
Проектированиефизическойреализацсистемыи
Наэтомэтапепроектированиямоделибазданныхиприложенийдополняютсяобозначениями
ихразмещенияатехническихсредствахразрабатываемойсистемы. На |
рис. 12.15 приведено |
|||
изображениеразделениятаблицы" |
пациент "натриэкстента( |
|
|
|
<<Tablespace>> )в |
|
|||
соответствиипервойбуквойфамилиипациента.
Рис. 12.15. Экстентаблицы"Пациент"
ОсновнымипонятиямиUML,которыеиспользуютсянаданномэтапе, являютсяследующие:
• |
компонент– самостоятельныйфизическиймодуль системы; |
|||
• |
зависимость– связь |
между |
двумя элементами, при которой изменения в одном элем |
|
|
вызываютизменениядругогоэлемента; |
|||
• |
устройство– |
узел , |
не обрабатывающийданные; |
|
• |
процессор– |
узел , |
выполняющийобработку данных; |
|
• |
соединение– |
связь |
между |
устройствамии процессорами. |
Диаграммыразвертыванияпозволяютотобразитьнаединойсхемеразличныекомпоненты системы(программныеиинформационные) ихраспределениепокомплексутехнических средств( рис. 12.16 ).
Рис. 12.16. ФрагментдиаграммыразвертыванияИС
Такимобразом, припроектированиисложнойИСонаразделяетсяначасти, каждаяизних затемисследуетсоздаетсяотдельно. Внастоящеевремяиспользуютсядваразличных способат когоразбиенияИСнаподсистемы:структурное(илифункциональное)разбиение объектная(компонентная)декомпозиция.
СпозицийпроектированияИСсутьфункциональногоразбиенияможетбытьвыражена известнойформулой: " Программа = Данные + Алгоритмы ".Прифункциональной декомпозициипрограммнойсистемыееструктураописываетсяблок-схемами, узлыкоторых представляютсобой"обрабатывающиецентры" (функции),асвязимеждуузламиописывают движениеданных.
Приобъектномразбиениивсистемевыделяются"активныесущности" –объекты(или компоненты),которыевзаимодействуютдругдругом, обмениваясьсообщениямивыполняя соответствующиефункции(методы)объекта.
ЕслиприпроектированииИСразбиваетсянаобъекты, тодляеевизуальногомоделирования следуетиспользоватьUMLЕсли. восновупроектированияположенафункциональная декомпозицияИС, тоUMLненужениследуетиспользоватьрассмотренныеран структурные нотации.
Втожевремя, привыбореподходакразработкеИСследуетучитывать, чтовизуальные
моделивсеболееширокоиспользуютсявсуществующихтехнологияхуправления проектированиемсистем, сложность, масштабыифункциональнкоторыхстьпостоянно возрастают. Онихорошоприспособленыдлярешениятакихчастовозникающихприсоздании системзадачкак:физическоеперераспределенвычисленийданных, обеспечение параллелизмавычислений, репликацияБД, обеспечениебезопасностидоступакИС, оптимизациябалансировкинагрузкиИС, устойчивостьксбоямит.п. Визуализированные средствамиUMLмоделиИСпозволяютналадитьплодотворноевзаимодействиемежду заказчиками, пользователямикомандойразработчиков. Ониобеспечиваютясность представлениявыбранныхар итектурныхрешенийпозволяютпонятьразрабатываемую системувовсейееполноте.