Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Пример графического описания связей между отношениями

Читайте также:
  1. B) зазор между пластинкой и линзой
  2. CИТУАЦИОННЫЕ ЗАДАЧИ С ПРИМЕРАМИ РЕШЕНИЯ
  3. CИТУАЦИОННЫЕ ЗАДАЧИ С ПРИМЕРАМИ РЕШЕНИЯ
  4. CИТУАЦИОННЫЕ ЗАДАЧИ С ПРИМЕРАМИ РЕШЕНИЯ
  5. CИТУАЦИОННЫЕ ЗАДАЧИ С ПРИМЕРАМИ РЕШЕНИЯ
  6. F10 Menu– переключение между меню. Меню 1
  7. I Международного женского конгресса

На рисунке 10 представлены связи между отношениями, характеризующими контрагента.

 

Рисунок 10 – Связи с отношением Contractor

Во вновь построенных и преобразованных таблицах проверяются первичные ключи. Если первичный ключ таблицы оказывается слишком длинным, неудобным для идентификации строк и для поддержания связей в БД, то в таблицу вводится дополнительное поле – искусственный первичный ключ. Этот ключ может быть известен пользователю и играть роль кода или номера объекта или быть внутренним ключом, автоматически создаваемым СУБД и обрабатываемым приложением. Изменение первичного ключа в одной таблице распространяется на соответствующие внешние ключи связанных таблиц.

Для всех столбцов нормализованных таблиц, используя описание соответствующего атрибута, задается имя и подбирается формат (тип) данных из поддерживаемых СУБД. Подлежащие контролю ограничения атрибутов оформляются логическими выражениями на языке выбранной СУБД.

Затем в логическую структуру БД вносятся связи, заданные между сущностями концептуальной схемы. Способ представления связи в реляционной модели данных зависит от ее типа. Связь типа «один к одному» при обязательном участии каждого объекта в связи означает, что экземпляры связанных сущностей могут появляться только вместе – парами. Например, договор и его смета в схеме, представленной на рисунке 18. В таком случае обычно нецелесообразно разделять эти сущности по отдельным таблицам. Следует образовать одну таблицу с полным набором столбцом и первичный ключ одной из таблиц считать ключом объединяющей таблицы.

Другой возможный тип связи «один ко многим» реализуется созданием в таблице со многими связанными строками (со стороны связи, помеченной «М») дополнительных столбцов, образующих внешний ключ. Столбцами внешнего ключа должны стать столбцы первичного ключа, таблицы с единственной связываемой записью. Например, для реализации связи «один ко многим» между заказчиком с его заявками (см. рисунок 18) в таблицу «Заявка» следует включить внешний ключ – номер заказчика. Если в связи «один ко многим» сущность со стороны помеченной «М» является слабой и обязательно должна быть связана с одним экземпляром сущности со стороны помеченной «1», то для внешнего ключа такой связи устанавливается свойство контроля ссылочной целостности. Для примера связи заказчика с его заявками проверка ссылочной целостности необходима. Обычно связью «один ко многим» с контролем ссылочной целостности реализуется связь справочной таблицы с информационной. При этом одной строке справочной таблицы может соответствовать ноль или несколько строк в информационной таблице.

Последний тип связи «многие ко многим» (M:М) реализуется с помощью дополнительной связывающей таблицы, с которой каждая из исходных таблиц имеет связь «один ко многим». Для этого в связывающую таблицу вводятся в качестве внешних ключей первичные ключи связанных таблиц. Причем их объединение может стать первичным ключом в связывающей таблице. При необходимости структура связывающей таблицы может быть дополнена столбцами, содержащими атрибуты связи. Например, фрагменту концептуальной схемы вида представленному на рисунке 10 соответствует логическая схема, пред-



Рисунок 10 – Фрагмент концептуальной схемы

ставленая на рисунке 11:

Рисунок 11 – Представление связи «многие ко многим»

Схема данных в виде ER диаграммы, представленная на рисунке 10, построена с помощью программы ERWin 4.0.

Данное средство разработки также входит в набор, используемый в CASE технологиях. ERWin позволяет не только «рисовать» схемы данных, но и определять свойства атрибутов в сущностях, задать ключи и характеристики связей с целью последующего автоматического преобразования схемы в структуру базы данных. Для атрибутов можно определить физические характеристики (тип, размер, умалчиваемое значение и др.) в ориентации на определенный сервер. ERWin поддерживает процедуру проектирования баз для большинства настольных СУБД и серверов. На рисунке 12 представлено окно ERWin для задания домена возможных значений атрибута в виде нового пользовательского типа данных id при реализации базы в MS SQL Server. Таким образом, можно определить физические параметры атрибутов для каждой сущности. Аналогично сущностям могут быть описаны связи в схеме данных и заданы их свойства.

Загрузка...

 

Рисунок 12 – Логическая схема для процесса приема и исполнения заказа

На рисунке 13 приведен пример задания свойств связи «Заказчик R_1 Заявка» между сущностями «Заказчик» и «Заявка». Часть этого имени «R_1» будет использована в качестве идентификатора ограничения внешнего ключа в сущности «Заявка» для создания связи типа «ноль, один или много» (zero, one or more) с сущностью «Заказчик».

При задании в ERWin свойств всех атрибутов и связей далее можно автоматически сгенерировать структуру базы данных или построить скрипт на языке SQL выбранного сервера.

Рисунок 13 – Форма в ERWin 4.0 для определения типа данных id с целью последующего использования в описании столбцов таблиц

На полученной системе таблиц и столбцов для связывания строк из разных таблиц проверяется выполнимость всех запросов, необходимых для реализации функций пользователя.

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

Для сложных запросов предлагаются изменения структуры данных, сокращающие пути доступа. Одним из способов ускорения выполнения сложных запросов является создание дополнительных таблиц или включение дополнительных столбцов в существующие таблицы. Эти столбцы содержат внешние ключи для прямого связывания строк из таблиц, находящихся на концах длинного логического пути (профиля доступа). Так, если в рассмотренном ранее примере при изготовлении специальных конструкций необходимо часто обращаться к заказчику, то в соответствии со схемой на рисунке 11 для поиска адреса и телефона заказчика в запросе будут связываться записи четырех таблиц: «Описание специальной конструкции», «Договор и смета расходов», «Заявка» и «Заказчик». Для сокращения пути доступа можно в таблицу «Описание специальной конструкции» добавить столбец (внешний ключ), содержащий ссылку на номер соответствующего заказчика. Теперь запрос на поиск заказчика будет выполняться по двум таблицам: «Описание специальной конструкции» и «Заказчик». Внесение подобной избыточности изменений в структуру оправдано только в том случае, когда использование традиционных мер ускорения запроса созданием правильных индексов и ведение индексной статистики не дают требуемого эффекта.

Рисунок 14 – Пример задания свойств связи между сущностями
«Заказчик» и «Заявка»

Следующей важной задачей логического проектирования является определение групп (ролей) пользователей и их прав в БД. Для этого автоматизируемые функции разбиваются на группы в соответствии с задачами пользователей в предметной области. Так, в рассматриваемом примере появится группа диспетчеров, осуществляющих прием заявок, проектировщиков, формирующих смету и техническую документацию, бухгалтеров, администратора БД и т.д. Группам даются понятные имена, ставятся в соответствие данные (таблицы и столбцы таблиц), для которых устанавливаются необходимые права доступа (включение, удаление, чтение, изменение). Для пользователей определяются учетные записи, которые распределяются по группам.

Материалы данного этапа, обосновывающие результат логического проектирования, включаются в основную часть пояснительной записки.

Для описания структуры таблиц можно использовать нотацию выбранной СУБД. Схема реляционной БД в нотации СУБД MySQL представлена на рисунке 345. Схема реляционной БД в нотации СУБД MS SQL Server представлена на рисунке 347.

Добавить рисунки

При выполнении курсового проекта учащийся самостоятельно решает, будет ли он использовать CASE средства для автоматизации проектирования и документирования разработки базы. Вне зависимости от использования CASE средств, в пояснительной записке в качестве окончательных результатов этапа логического проектирования должны быть представлена логическая схема, определены и детально описаны свойства и ограничения всех атрибутов сущностей и их связей.

 

3.3 Содержание раздела «Физическое проектирование базы данных»

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

- основные требования к реализации физической модели (описание таблиц);

- количество и типы используемых носителей информации;

- количество и размеры файлов операционной системы, в которых размещается база данных, их расположение на носителях информации;

- типы, количество и режимы обновления индексов для пользовательских таблиц и представлений;

- резервирование свободных областей памяти при загрузке базы, частота и способы реорганизации (уплотнения) базы данных;

- способы и средства обеспечения надежности (резервирования и восстановления) данных.

Описание таблиц в пояснительной записке

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

Таблица 1– Структура таблицы Users

Наименование поля Тип поля Назначение Заполнение
Id int Первичный ключ автозаполнение
Users varchar Название учетной записи обязательно
Indentifical varchar Пароль в зашифрованном виде обязательно
Date_beg datetime Дата начала действия обязательно
Date_end datetime Дата окончания действия  
Working bit Признак окончания действ.  
Foto image Автор (Фотография)  
S1 bit Признак доступа к справочнику «Подразделений и отделов» обязательно (умолч. - false)
S2 bit Признак доступа к справочнику «Источники финансовых средств» обязательно (умолч. - false)
S3 bit Признак доступа к справочнику «Статей расходов и материалов» обязательно (умолч. - false)
Rpln bit Признак доступа к модулю «Роспись плана» обязательно (умолч. - false)
Lpln bit Признак доступа к модулю «Учет изменений в росписи плана» обязательно (умолч. - false)
Rgpln bit Признак доступа к модулю «Роспись годового плана государственных закупок» обязательно (умолч. - false)
Lgpln bit Признак доступа к модулю «Учет изменений в росписи годового плана государственных закупок» обязательно (умолч. - false)
del bit Признак доступа к модулю «Удаление данных из справочников» обязательно (умолч. - false)

В отдельных случаях права группы должны быть ограничены подмножествами строк в таблицах базы. Для реализации таких ограничений в структуру базы необходимо ввести представления, в которых с помощью оператора SELECT определяется подмножество доступных столбцов и строк. Группам пользователей даются необходимые права работы через представления.

В пояснительной записке в качестве окончательных результатов этапа физического проектирования должны быть приведены структуры таблиц и представлений базы с описанием назначения их столбцов и контролируемых ограничений. Обоснованы необходимые роли пользователей и их права в базе данных.

Решения, принимаемые на этапе физического проектирования, мало влияют на логические возможности обработки данных, но в значительной мере определяют времена выполнения запросов и объемы расходуемой памяти. Использование средств, предоставляемых СУБД для физического проектирования, позволяет увеличить скорость выполнения одних запросов за счет дополнительного расхода памяти и снижения скорости других. Задача разработчика БД - обеспечить максимальную эффективность работы с БД за счет повышения производительности наиболее частых запросов.

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

Вопросы физического проектирования освещаются в пояснительной записке в разделе «Физическое проектирование».

Если на предыдущих этапах в процессе обследования, документирования и проектирования БД использовались средства автоматизации разработки информационных систем (CASE средства), то основная часть работы по написанию скрипта и генерации базы может быть выполнена автоматически используемым CASE средством. При ручном проектировании в создании базы участвуют только средства используемой СУБД.

Заканчивается процесс проектирования созданием структуры БД и учетных записей пользователей в выбранной СУБД. При этом необходимо стремиться представить в определении объектов базы наибольшее количество свойств предметной области с тем, чтобы максимально разгрузить приложение от проверки правильности данных и целостности базы. В зависимости от выбранной СУБД структура данных создается либо в интерактивном режиме с помощью графического интерфейса, либо написанием скрипта (программы на DDL), который создает новую пустую БД. При любом способе создания необходимо предусмотреть возможность быстрого восстановления структуры базы данных (копированием, выполнением сценария и др.).


3.4 Содержание раздела «Проектирование запросов на языке SQL»

В результате выполнения курсового проекта требуется построить запросы на языке SQL, указанные в варианте задания. Учащимися формулируются запросы к базе данных. Приводится их естественно-языковое описание и представление в формате SQL с результатами выполнения.

Могут быть построены следующие виды запросов:

- запросы на выборку, включая параметрические;

- запросы на выборку с группировкой;

- запросы на создание таблиц и удаление записей из таблиц;

- запросы для переноса информации за предыдущие периоды в архив;

- перекрестные запросы;

- запросы, определяющие права доступа пользователей к данным.

Пример:

Основными запросами в курсовом проекте являются:

а) запрос, который применяется для состава меню:

Листинг 1 –Запрос, определяющий состав меню

SELECT Goods.gname, Me_G.mid AS Me_G_mid, Me_G.gid AS Me_G_gid, Menu.mid AS Menu_mid, Menu.mdate

FROM Menu INNER JOIN (Goods INNER JOIN Me_G ON Goods.gid = Me_G.gid) ON Menu.mid = Me_G.mid

WHERE (((Menu.mdate)=[Forms]![CreateMenu]![mdate]));

б) запрос на проверку занятости места:

Листинг 2 –Запрос проверяющий занятость места

SELECT Count(Zakaz.timed) AS Количество

FROM Zakaz INNER JOIN PL_Zak ON Zakaz.zid = PL_Zak.zid

GROUP BY Zakaz.zdate, PL_Zak.pid

HAVING (((Count(Zakaz.timed))=[Forms]![Zakaz]![ПолеСоСписком21]) AND ((Zakaz.zdate)=[Forms]![Zakaz]![zdate]) AND ((PL_Zak.pid)=[Forms]![Zakaz]![ПолеСоСписком24]));

в) перекрестный запрос, для отображения принадлежности мест к столам:

Листинг 3 –Перекрестный запрос отображающий принадлежность мест к столу.

TRANSFORM Count(T_P.kol) AS [Count-kol]

SELECT T_P.Tables.tid, Count(T_P.kol) AS [Итоговое значение kol]

FROM T_P

GROUP BY T_P.Tables.tid

PIVOT T_P.pid;

Далее в курсовом проекте описываются и обосновываются представления, хранимые процедуры, триггеры.

На второй стадии курсового проектирования выполняется разработка программы, реализующей автоматизированные функции пользователей и дополнительные функции администратора для обслуживания БД.

Разработка программы предполагает последовательное выполнение этапов технического и рабочего проектирования.

На этапе технического проектирования разрабатываются алгоритмы и принимаются решения по функциям, структуре, интерфейсам и защите программного обеспечения. В процессе технического проектирования программы, предназначенной для работы с базой данных, решаются следующие задачи.

1 Производится классификация и распределение автоматизируемых функций по пунктам меню главного диалогового окна пользователя. В один класс следует включать функции, объединяемые общей логикой применения или общими используемыми объектами.

2 Выделяются наиболее употребительные функции, которые целесообразно представить кнопками в общих для многих экранных форм панелях инструментов.

3 Выбираются функции, для эффективной реализации которых целесообразно использовать хранимые процедуры. Для сложных функций разрабатываются алгоритмы, в необходимых случаях представляемые блок-схемами и текстовыми описаниями.

4 Решаются вопросы динамики (изменения объема) БД. Определяются условия и режим (автоматически или пользователем) архивирования неактуальных данных. Создается перечень функций, необходимых для архивирования базы и работы с архивом.

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

6 В системах для многих пользователей определяются полномочия (права) пользователей по работе с функциями и данными. Устанавливается необходимый уровень изоляции транзакций, выполняющих функции и хранимые процедуры. В необходимых случаях предусматриваются индивидуальные блокировки данных в операторах транзакций.

7 Решается вопрос защиты программы от постороннего доступа и выбирается комплекс мер по организации защиты программы и отдельных функций.

8 Определяется тип диалога в виде одно- или многодокументального интерфейса для функций пользователя. Разрабатываются экранные формы для организации диалога при выполнении функций и структура создаваемых программой документов (отчетов, справок, писем и т.д.). Создание макетов экранных форм и отчетов следует выполнять средствами визуального программирования, если они имеются в выбранном инструменте разработки, совмещая этим этапы технического и рабочего программирования.

9 Разрабатываются описания экранных форм и контекстных подсказок, подключаемых в качестве оперативной помощи (Help) пользователю.

10 Продумывается способ установки программной системы на компьютер пользователя и ее переустановки в случае отказа компьютера.

На этапе рабочего проектирования создается структура программной системы. Структура программы должна строиться по модульному принципу так, чтобы самостоятельные функции были реализованы отдельными модулями или методами объектно-ориентированного программирования и допускали автономные изменения. Функции распределяются по программным модулям.

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

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

Программы, реализующие функции пользователя, должны в начале контролировать выполнимость функции (наличие всех данных, готовность устройств и т.д.) и сообщать о недостающих ресурсах, а в процессе выполнения перехватывать исключения среды программирования и СУБД, заменяя их понятными пользователю сообщениями.

Для создания приложения могут быть использованы любые технологии работы с базами данных и средства программирования. Приложение может быть создано и по WEB технологии с ориентацией на Internet Explorer 6.0. При программировании следует максимально использовать инструментальные средства выбранной системы разработки приложений. Выбирая среду разработки надо иметь в виду, что использованные средства должны быть доступны при защите проекта в компьютерном классе.

Решения, принятые на этапах технического и рабочего проектирования, подробно отражаются в разделе «Реализация законченного приложения, работающего с созданной базой данных» пояснительной записки. В разделе должна быть обоснована и описана организация диалогов пользователя и структура программы, приведена спецификация программных модулей (экранных форм, отчетов, подпрограмм и т.д.) с указанием имени, назначения, параметров, способов и мест вызова. Для модулей, реализующих логические и вычислительные задачи, приводятся блок-схемы и тексты программ или хранимых в базе процедур.

Далее подробно рассмотрим оформление в пояснительной записке описание процедур, триггеров, функций, ограничений.


Дата добавления: 2015-07-08; просмотров: 201 | Нарушение авторских прав


Читайте в этой же книге: Цели и задачи курсового проектирования | Тема курсового проекта | Основная часть | Анализ предметной области | Концептуальное проектирование базы данных | Обеспечение целостности (Check Constraints) | Разработка приложения | Безопасность и защита данных | Тестирование программного продукта | Анализ предметной области |
<== предыдущая страница | следующая страница ==>
Логическое проектирование базы| Разработка хранимых процедур (Stored Procedure)

mybiblioteka.su - 2015-2021 год. (0.019 сек.)