Визуальное моделирование
жүктеу/скачать 10,86 Mb.
|
bibliofond.ru 656650
Obrazets-zapolneniya-soglasiya-na-obrabotku-personalnyh-dannyh-2021
- Бұл бет үшін навигация:
- Т_Рецепт
- Т_Лекарства
| Хранимая процедура (Stored procedure) - независимая процедурная функция, выполняемая на сервере.
Домены (Domains) - допустимый набор значений для атрибута или столбца. Кроме данных сущностей могут быть введены и некоторые дополнительные сущности, отражающие специфические аспекты модели БД. На основе диаграммы классов модно создать профиль базы данных (диаграмма реляционных таблиц системы). При этом следует иметь ввиду, что объектно-ориентированная модель системы и профиль баз данных далеко не одно и то же. Реляционная модель не поддерживает наследования, имеет типы данных, соответствующие используемой СУБД, для обеспечения связей между таблицами используются специальные кодовые поля. Остановимся на основных моментах в преобразовании объектно-ориентированной модели в реляционную: ) основные классы, содержащие данные, предназначенные для хранения, преобразуются в таблицы; ) при наличии ассоциаций типа «один к одному» хотя бы с одной стороны нужно добавить дополнительное кодовое поле, где указать код (ключ) второй записи для обеспечения связи данных; ) при наличии ассоциаций типа «один ко многим» со стороны подчиненных записей (со стороны «многие») необходимо ввести дополнительное поле, где указать код (ключ) записи, которой они подчиняются (со стороны «один»); ) при наличии ассоциаций типа «многие ко многим» необходимо ввести дополнительную таблицу связей, содержащую минимум два поля: код одного участника и код второго участника, таким образом ассоциация типа «многие ко многим» преобразуется в две ассоциации типа «один ко многим» через таблицу связи; ) при наличии класса-ассоциации класс-ассоциация вводится как таблица связи, имеющая дополнительные атрибуты. ) при наличии обобщения необходимо дополнить исходную таблицу полями, соответствующими атрибутам суперкласса (тогда суперкласс не вводить как таблицу), или ввести таблицу суперкласса (с полями соответствующими его атрибутам) а в таблице, соответствующей исходному классу добавить поле, соответствующее коду (ключу) записи суперкласса. Если реляционная модель была построена на базе хорошо продуманной объектно-ориентрованной модели, полученная реляционная модель обычно не содержит аномалий обновления и удаления информации и удовлетворяет условиям нормализации. Однако полезно проверить полученную реляционную модель на соответствие нормальным формам. На рис. 8. приводится диаграмма профиля данных для разрабатываемой информационной системы «Аптека». Структура базы данных соответствует третьей нормальной форме. В соответствии разработанной объектно-ориентированной моделью определим таблицы на базе классов, соответствующих основным концептуальным сущностям информационной системы. Каждой соответствующей таблице дадим имя, начинающиеся на букву «Т» и включающие имя соответствующего класса, например, Т_Лекарства. Таблицы UML являются стереотипными классами со стереотипом «Table», вид пиктограммы может регулироваться опцией Stereotype Display. Структура классов содержит классы с иерархическими связями наследования: персона, фармацевт, врач. В соответствии с рекомендациями разработки реляционного профиля при наличии наследования базовых классов необходимо либо транслировать все атрибуты предков в таблицы, соответствующие листовым классам иерархии наследования; либо вводить таблицы, соответствующие всем классам иерархии наследования с обеспечением связей между таблицами от потомка к предку. Мы изберем компромиссный вариант: класс медикаменты в отдельную таблицу преобразовывать не будем, соответствующие атрибуты транслируем в таблицы, соответствующие классам рецепт (Т_Рецепт) и лекарства (Т_Лекарства). Такой подход позволяет сэкономить внешнюю память, не прибегая к большому увеличению связей. Таблицы T_Фармацевт и Т_Врач будут содержать столбцы соответствующие только специфическим атрибутам и по полю ID_Persona связываться с таблицей Т_Персона, содержащий всю основную информацию о врачах и фармацевтах. Для выполнения условия атомарности атрибутов, атрибуты класса Т_Адрес непосредственно транслируем в таблицы Т_Персона. Разбиение адреса на несколько атрибутов позволяет расширить возможности поиска и сортировки данных по адресу проживающих. Для обеспечения связи по типу «один ко многим» между врачом и рецептом, а также, врачом и лекарствами в таблицы Т_Рецепт и Т_Лекарства для записи каждого врача указывается код врача. Аналогично для связи между фармацевтом и лекарствами в таблице Т_Лекарства указывается код фармацевта. Веденные через перечисления специализированные типы в реляционных таблицах кодируются типом INT (целое), соответствие между кодами и их значением обеспечивается средствами интерфейса конечной программы (например, с помощью элемента ListBox VCL). Текстовые атрибуты типа String объектно-ориентированной модели преобразуются в поля типа CHAR с указанием длины в текстовых символах. На этапе проектирования реляционного профиля баз данных в проект могут быть введены существенные изменения: изменены или введены новые атрибуты сущностей, пересмотрены связи, даже определены новые сущности, преобразующиеся в классы. Итак, мы рассмотрели базовые этапы разработки информационной системы: разработку концепции, вида с точки зрения прецедентов, вида с точки зрения проектирования, реляционного профиля баз данных. Последующие этапы непосредственно связаны с программированием в конкретной системе программирования. На этапах непосредственной разработки программы, используя средства обратного проектирования можно возвращаться к пересмотру и уточнению разработанной в UML модели. UML также позволяет отразить завершающие этапы разработки средствами диаграмм компонентов и размещения, что может в дальнейшем облегчить установку и сопровождение программного продукта. Используя UML, разработчик практически не зависит от организации процесса программирования; он не привязан к какому-либо конкретному циклу изготовления программного продукта. Тем не менее, разработчиками UML рекомендуется применять процесс, который: управляется прецедентами использования; основан на архитектуре; является итеративным и инкрементным. Управляемость прецедентами использования означает, что прецеденты должны быть основным артефактом, на основании которого устанавливается желаемое поведение системы, проверяется и подтверждается правильность выбранной системной архитектуры, производится тестирование и осуществляется взаимодействие между участниками проекта. Процесс называют основанным на архитектуре (Architecture-centric), когда системная архитектура является решающим фактором при разработке концепций, конструировании, управлении и развитии создаваемой системы. Итеративным (Iterative) называется процесс, который предполагает управление потоком исполняемых версий системы. Инкрементный (Incremental) процесс подразумевает постоянное развитие системной архитектуры при выпуске новых версий, причем каждая следующая версия усовершенствована в сравнении с предыдущей. Процесс, являющийся одновременно итеративным и инкрементным, называется управляемым рисками (Risk-driven), поскольку при этом в каждой новой версии серьезное внимание уделяется выявлению факторов, представляющих наибольший риск для успешного завершения проекта, и сведению их до минимума. Средства языка UML дают широкие возможности по использованию управляемого прецедентами, основанного на архитектуре, итеративного и инкрементного процесса разработки программного обеспечения. жүктеу/скачать 10,86 Mb. Достарыңызбен бөлісу:
|