Методические указания к курсовому проекту по дисциплине «базы данных»




НазваниеМетодические указания к курсовому проекту по дисциплине «базы данных»
страница2/3
Дата конвертации22.12.2012
Размер0.55 Mb.
ТипМетодические указания
1   2   3

Сотрудники

Табномер



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



Паспорт



  • связь отображается ромбом с именем связи внутри. Ромб линиями соединяется с прямоугольниками связанных сущностей. Одна линия – частичная степень участия, две линии – полная степень участия. Над каждой линией ставится показатель кардинальности. Например,


1

1



имеет





Паспорт
Сотрудники

Табномер


Этап логического проектирования

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

2.2.1. ER-диаграмма в среде ERwin.

Для построения ER-диаграммы в среде ERwin (стандарт IDEF1X) используют данные из таблиц № 2.1 и 2.2 или КМД, построенную на этапе концептуального проектирования.

При запуске среды ERwin необходимо внимательно заполнять все появляющиеся окна. В первом окне нужно выбрать режим создания новой модели или открыть существующую ER-диаграмму (см. рис. № 2.1).




Рис.2.1. Вид 1-го окна при запуске CASE –средства ERwin.


Во втором окне необходимо выбрать этапы проектирования, которые будут выполняться – для выполнения курсовой работы это этап Logical/Physical (см. рис. № 2.2), в этом случае становится активной нижняя часть окна, где необходимо выбрать целевую СУБД (на рис. № 2.2 – это SQL Server).





Рис. 2.2. Вид 2-го окна при запуске CASE –средства ERwin.


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

При нажатии кнопки «ОК» во втором окне открывается рабочее окно в среде ERwin, имеющее несколько строк, приближенных по своему виду и функционалу к стандарту Microsoft Office (см. рис. № 2.3).

Первая строка – строка заголовка, содержащая имя (путь) файла, содержащего модель, которая в текущий момент находится в рабочем окне, по умолчанию modelN.er, где N - номер открываемого в среде ERwin окна по порядку. Первая строка имеет стандартные кнопки – свертывания, изменения размера и закрытия рабочего окна.

Вторая строка – строка главного меню - содержит все команды, которые можно выполнять в CASE-средстве Erwin, в том числе как привычные, например относящиеся к работе с файлами - «открыть», «сохранить», «сохранить как», так и специальные, например выбрать стандарт проектирования модели.





Рис. 2.3. Вид рабочего окна при запуске CASE –средства ERwin.


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

Четвертая строка - так называемая панель форматирования, почти полностью повторяет стандарт Microsoft Office с добавлением кнопок «отмена действия нажатой кнопки», «создать сущность», «связь суперкласс/подкласс», «идентифицирующая связь», «связь многие-ко-многим», «неидентифицирующая связь». Именно с помощью этих кнопок создается модель (см. рис. № 2.4).



1 2 3 4 5

Рис.2.4. Часть панели форматирования с кнопками для создания модели.


Для отображения сущности необходимо нажать кнопку 1 (см. рис. № 2.4), указатель курсора поменяет свой вид на крестик, что позволит, щелкнув мышью, показать местоположение в рабочем окне сущности. В рабочем окне появится:



Сущность отображается прямоугольником, разделенным на две части. Над прямоугольником выделено имя и номер сущности – Е/5 (сущность – Entity № 5). Выделение говорит о том, что мы можем изменить имя сущности, просто набирая на клавиатуре нужное нам:



Обратите внимание - размер прямоугольника изменится таким образом, чтобы имя сущности читалось целиком. Размер и положение сущности меняется привычным в Microsoft Office способом работы с объектами. Если необходимо изменить имя сущности - щелкните дважды по нему мышью, появится окно работы с сущностью – рис.2.5, и в строке Name можно вписать другое имя.




Рис.2.5. Изменение имени в окне работы с сущностью.


Для того чтобы в вести атрибуты сущности, необходимо добавить эти атрибуты в окне ввода нового атрибута окна работы с атрибутами - рис.2.6. При этом пишется имя атрибута и выбирается один из четырех предлагаемых типов атрибута:

Blob – логический и OLE-тип,

Datetime – время-дата,

Number - числовой,

String – символьный тип.

Для работы с введенными атрибутами – изменения имени, уточнения типа, удаления атрибута, а также для указания, является ли выбранный атрибут первичным ключом, значения атрибута по умолчанию - открывается окно работы с атрибутами – рис. 2.7.




Рис.2.6. Добавление нового атрибута в окне ввода атрибута.


На рис. 2.7. показано назначение введенного атрибута «Табном» сущности «Персонал» первичным ключом. При нажатии на кнопки, расположенные в нижней части окна, можно:

New… - открыть окно ввода нового атрибута;

Rename… - изменить имя выбранного атрибута;

Delete – удалить выбранный атрибут.

Для уточнения типа атрибута, для указания значения атрибута по умолчанию в правой части окна работы с атрибутами выбирается вкладка Datatype. На рис. 2.8. показано, что для атрибута FIO тип принимается как varchar (55) – не более 55 символов.

Необходимо отметить, что первичный ключ располагается в верхней части прямоугольника («на крыше»), все остальные атрибуты – в нижней. Можно указателем мыши переносить атрибуты «с крыши» вниз и наоборот, меняя таким образом первичный ключ.





Рис.2.7. Окно работы с атрибутами.


После ввода всех атрибутов желательно изменить высоту прямоугольника таким образом, чтобы были видны все атрибуты и оставалось место примерно еще для двух атрибутов – см. рис. 2.9.

У изображения сущности можно менять шрифт, его размер, цвет шрифта, цвет фона и линий аналогично тому, как это делается в среде Microsoft Word.

Для установления связей между сущностями необходимо пользоваться кнопками 2-5 (см. рис.2.4.).

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

Для отображения связей с показателями кардинальности 1хМ и 1х1 используют:

кнопку 4 – «идентифицирующая связь», она переводит первичный ключ сущности с кардинальностью «1» в качестве обычного, внешнего атрибута в сущность с кардинальностью «М»;

кнопку 5 – «неидентифицирующая связь», она переводит первичный ключ сущности с кардинальностью «1» в качестве первичного, внешнего атрибута в сущность с кардинальностью «М».





Рис. 2.8. Уточнение типа атрибута.




Рис. 2.9. Отображение сущности в CASE-средстве Erwin.


Для того, чтобы зафиксировать свойства связи, используют окно «Свойства связи» (Relationship Property), вызываемое из контекстного меню правой кнопки мыши одноименной строчкой (см. рис.2.10).

В этом окне указывается имя связи: в нашем примере - «заключает» и степень участия в этой связи сущности с кардинальностью «1», так называемой «родительской» сущности: в нашем примере - экземпляры сущности «Персонал» могут не принимать участие в связи «заключает», то есть не заключать договора ( например, лаборанты ), а могут принимать, то есть заключать М договоров. Если же все экземпляры сущности «Персонал» принимают участие в связи «заключает», то необходимо выбрать строчку “One or More (P)”.

Для связи с показателем кардинальности 1х1 выбираются строки “Zero or One (Z)” и “Exactly”. Если выбирается строка “Zero or One (Z)”, экземпляры сущности «Персонал» могут не принимать участие в связи «заключает», то есть не заключать договора, а могут принимать, то есть заключать, только 1 договор. Если выбирается строка “Exactly”, необходимо указать конкретную цифру. В этом случае экземпляры сущности «Персонал» обязательно принимают участие в связи и заключают конкретное количество договоров.





Рис. 2.10. Окно «Свойства связи» в CASE-средстве Erwin.


Если две сущности связаны друг с другом двумя или более разными связями, а также в случае рекуррентных (ролевых) связей, необходимо указать ролевые имена, с которыми эти сущности вступают в связь. Для этого в окне «Свойства связи» (Relationship Property) открывают вкладку «Ролевые имена» (Rolename) (см. рис. 2.11) и в строке «Ролевое имя» (Rolename) указывают имя – в данном примере для связи «доставляют» ролевое имя - «курьер». Ролевое имя используется в качестве имени внешнего атрибута, по которому передается первичный ключ.

Для отображения связи «суперкласс-подкласс» используется кнопка 3. При этом сначала щелкают мышью по кнопке 3 – выбирают тип связи, затем щелкают по сущности-суперклассу, затем по сущности-подклассу. Если у сущности-суперкласса есть несколько сущностей-подклассов, то для их включения используется кнопка 4, сначала щелкают по кнопке, затем – по значку связи, а затем – по сущности-подклассу. Для связи «суперкласс-подкласс» необходимо указать степень вхождения подклассов в суперкласс в окне “Subtype Relationships” (см. рис. 2.12), вызываемое правой кнопкой мыши. “Complete” – сущность-суперкласс состоит только из экземпляров сущностей-подклассов; “Incomplete” - сущность-суперкласс состоит не только из экземпляров сущностей-подклассов. На рис. 2.12. изображен пример неполного вхождения сущностей-подклассов в сущность-суперкласс: «Персонал» состоит не только из «Менеджеры» и «Операторы».





Рис. 2.11. Вкладка “Ролевые имена” (“Rolename”).


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

Для отображе6ния связи с показателем кардинальности МхМ используется кнопка 5. Передача ключа при этой связи не происходит (см. рис. 2.13).

При отображении всех сущностей и связей, заявленных в таблицах

2.1 и 2.2., получается ER- диаграмма в стандарте IDEF1X.





Рис. 2.12. Окно “Subtype Relationships”.


2.2.2. Анализ ER- диаграммы.

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

Многозначные атрибуты – меняются на сущность с именем многозначного атрибута и связь с показателем кардинальности «1 х М». См. рис. 2.13 – атрибут «телефон» сущности «Клиент» заменен на сущность «Телефон». Обратите внимание, что в сущности «Клиент» такого атрибута уже нет.

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

Рекурсивные связи – возможно требуют добавления сущности или сущности-подкласса и связи с показателем кардинальности «1 х М».

Связи с показателем кардинальности «1 х 1» - требуют дополнительного анализа, действительно ли это две разные сущности или возможно объединение в одну сущность.

Избыточная связь – связь, соединяющая две сущности, соединенные друг с другом набором других связей и не несущая дополнительных данных. Обычно на этом этапе удаляется до 80% избыточных связей. На рис. 2.13 видно, что связь «заключают» заменена на связи «менеджер-договор» и «оператор-договор» как несущие дополнительные данные.

Связи с показателем кардинальности «М х N» - анализируются на наличие собственных атрибутов.

Все проведенные изменения обязательно фиксируются. Измененная ER- диаграмма является результатом данного этапа проектирования и считается окончательной ER-диаграммой. Например, ER- диаграмма на этом этапе может принимать вид, как на рис. 2.12.


2.3. Этап физического проектирования.

Этап физического проектирования всегда тесно связан с особенностями конкретной выбранной СУБД.



Рис. 2.12. Пример связи с показателем кардинальности МхМ.


2.3.1. Генерация базы данных.

На этапе физического проектирования в ER-диаграмме для всех атрибутов уточняются все типы данных, чтобы убедиться в их применении в выбранной среде реализации. Для этого в CASE-средстве Erwin достаточно выбрать физический этап проектирования в пиктографическом меню (см. рис. 2.14). Все имеющиеся связи с показателем кардинальности «М х N» раскрываются в ассоциативные таблицы. Чтобы получить ассоциативную таблицу, необходимо поставить курсор на связь с показателем кардинальности «М х N»и нажать на правую кнопку мыши, выбрать из всплывающего меню строчку ”Create Аssociative Table” и последовательно нажимать «OK» во всех диалоговых окнах. Пример вида окончательной ER-диаграммы представлен на рис. 2.13.



Рис. 2.13. Пример ER-диаграммы на этапе физического проектирования.


Для генерации таблиц и схемы данных в выбранной СУБД необходимо выполнить следующие действия:

cоздать пустой файл базы данных;

выполнить команду “DataBase” – “DataBaseConnection” и в появившемся диалоговом окне в строке “DataBase” выбрать полный путь к созданному пустому файлу;

выполнить команду “Tools” – “Forward Engineer” - «OK».




Рис. 2.14. Переход к физическому этапу проектирования.


3.Проектирование пользовательских интерфейсов.

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

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

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


3.1. Список требований пользователей.

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

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

Менеджер:

Список всех операторов.

Перечень всех договоров конкретного менеджера за конкретный месяц.

Поиск информации об операторе по его ФИО.

Оператор:

Ввод нового договора.

Поиск объекта по цене.

Ввод нового клиента.

Поиск всех договоров конкретного клиента.

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

Продавец:

Поиск товара по названию и цене «от» - «до»

Поиск товара по марке-производителю.

Формирование чека.

Список всех своих чеков за период.

Невозможны в этом случае транзакции:

Продавец:

Ввод нового товара – относится к описанию функции поставок.

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

Для включения в специализацию транзакций при выполнении курсового проекта следует избегать транзакций типа Delete (удаление) и типа Update (обновление).


3.2. Анализ транзакций на этапе логического проектирования.

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

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

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

Список всех операторов.

Для выполнения данной транзакции необходимо найти значение первичного ключа – номера данного менеджера среди значений данного атрибута сущности «Менеджеры». Если такой номер не будет найден, необходимо вывести сообщение о том, что такого менеджера не существует. Если будет найден, далее необходимо найти связь с сущностью «Операторы». Такая связь есть через сущность «Персонал», но эта связь не позволяет определить, кто из персонала подчиняется данному менеджеру. Данную транзакцию выполнить нельзя. Необходимо добавить связь «Менеджеры» - «управляют» - «Операторы», показатель кардинальности которой «1 х М». В этом случае по этой связи мы найдем данные обо всех операторах в сущности «Операторы», у которых значение атрибута “Таб_ном_мен” равен заявленному. Результат анализа данной транзакции и все необходимые исправления модели данных приведены на рис. 3.1.

Перечень всех договоров конкретного менеджера за конкретный месяц.

Для выполнения данной транзакции необходимо найти значение первичного ключа – номера данного менеджера в сущности «Персонал», далее найти значения всех атрибутов в сущности «Договор», где значение атрибута “менеджер” совпадает с заданным и значение атрибута “Дата_закл” попадает в границы заданного месяца. Данная транзакция может быть выполнена. Результат анализа данной транзакции и все необходимые исправления модели данных приведены на рис. 3.1.

Поиск информации об операторе по его ФИО.

Для выполнения данной транзакции необходимо найти заданное значение атрибута “FIO” в сущности «Персонал». Если такого значения нет, необходимо вывести сообщение об ошибке, если таких значений одно или больше, а это возможно, так как атрибут “FIO” не является первичным ключом, и для всех этих значений необходимо найти значения первичных ключей «Таб_ном» и всех остальных атрибутов, так как они содержат данные об искомых операторах, и далее найти значения всех атрибутов в сущности-подклассе «Операторы», где значения первичных ключей совпадают с найденными. Данная транзакция может быть выполнена. Результат анализа данной транзакции и все необходимые исправления модели данных приведены на рис. 3.1.

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


Документация на пользовательские интерфейсы.

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


Рис. 3.1. Пример визуального отображения анализа транзакций на этапе логического проектирования.




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

Документация на пользовательские интерфейсы содержит следующие разделы:

Постановка задачи.

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

ПИ обеспечивает деятельность оператора по заключению договора на аренду жилья:

Поиск или ввод клиента;

Поиск объектов жилья по требованию клиента:

По ближайшей станции метро и/или цене «от»-«до»;

По количеству комнат и/или метражу жилой площади;

По наличию телефона и/или мебели;

Оформление договора.

Исходные данные.

Исходные для ПИ данные делятся на:

Переданные из БД.

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

Поле «Полный адрес объекта» берется из таблицы Объект(Адрес)

Поля ФИО, дата рождения, прописка клиента – таблица Клиент(ФИО, Д_рож, адрес)

Поля Паспортные данные – таблица Паспорт(номер, серия, кто, когда)

Поле Стоимость – таблица Объект(ст-ть)

Количество месяцев.

Введенные вручную.

Обычно в ПИ оформляются как поля ввода (текстовые поля). Необходимо перечислить все поля ПИ, которые вводятся вручную. Например:

ФИО клиента

Номер и серия паспорта

Цена «от»

Цена «до»

Начало аренды

Конец аренды.

Справочные константы.

Обычно в ПИ оформляются как метки, поля ввода (текстовые поля) с уже введенными данными, поля со списком выбора, метки с «переключателем». Необходимо перечислить все поля ПИ, которые содержат справочную информацию и ее источник. Например:

ближайшая станция метро – список всех станций метрополитена.


3.3.3. Алгоритм решения.

Если в ПИ проводятся какие-либо вычисления, необходимо пояснить их алгоритм либо в виде формул, либо в виде блок-схемы, либо в виде текста с пояснениями. Например:

стоимость по договору = стоимость * количество месяцев

количество месяцев = конец аренды – начало аренды.

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


3.3.4. Макет интерфейса.

Если ПИ имеет только одну экранную форму – представлять нужно только ее, если несколько – представлять нужно все формы с указанием условий переходов и возвратов от одной формы к другой. Например:

Рис. 3.2. Макет пользовательского интерфейса.




3.3.5. Перечень всех управляющих элементов макета.

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

Таблица №3.1 Описание управляющих элементов.

Номер управляющего элемента

Имя элемента

Какие действия выполняются

ComboBox1




Позиционирование конкретного оператора

Buttom1

Найти

Поиск данных о клиенте по номеру и серии паспорта

Buttom2

Добавить клиента

Добавление данных о новом клиенте

Buttom3

Просмотреть список договоров клиента

Просмотр всех договоров найденного клиента

ComboBox2




Выбор станции метро из всего списка станций

ComboBox3




Выбор количества комнат из возможного в компании списка (1,2,3,4)

ComboBox4




Выбор типа дома из возможного в компании списка.

Buttom4

Найти

Поиск варианта квартиры по одному или любому набору представленных параметров.

ComboBox5




Выбор месяца

Buttom5

Заключить договор

Добавление данных нового договора. В результате добавления в окне «Номер договора» автоматически появится следующий номер договора.

В окне «Количество договоров за день» происходит увеличение на 1.

В окне «на сумму» происходит увеличение на сумму добавленного договора.

Buttom6

Распечатать договор

Происходит распечатка шаблона договора, хранящегося в MSWord с добавлениями полей таблицы «Договор»


Программный код.

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

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


Реализация транзакций средствами выбранной СУБД.

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

В курсовой проект включаются 10 реализованных средствами СУБД транзакций. Описание реализованных транзакций делается в виде таблицы (см. таблицу №3.2)


Таблица №3.2. Описание реализованных в СУБД MS Access транзакций.

Имя или номер транзакции по спецификации транзакции

Форма реализации


Имя реализации.

Т12. Выбор сотрудников с должностью оператор

Запрос

Операторы

Т27. Список договоров, содержащий информацию об арендованных объектах

Сохраняемый запрос

Список_договоров


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


Анализ транзакций на этапе физического проектирования.

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

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

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

отношения и атрибуты, к которым потребуется иметь доступ при выполнении транзакции, а также тип этого доступа ( R – выборка, I – вставка, U – обновление, D – удаление );

ограничения, устанавливаемые на время выполнения транзакций.

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



Сущности

Количество входящих стрелочек

Персонал

3

Менеджеры

1

Операторы

2

Договор

1


Так как в нашем примере анализировалось небольшое количество транзакций, то количество входящих стрелочек для всех сущностей примерно одинаково. Обычно 2-3 сущности имеют значительно большее количество, чем все остальные. На этапе физического проектирования целесообразно анализировать только те транзакции, которые включают обращения к отношениям с большим количеством входящих стрелочек. В нашем случае это сущности «Персонал» и «Операторы», через которые проходят все заявленные в нашем примере транзакции. Обычно остается для анализа на физическом этапе проектирования около 80% всех транзакций.

Далее необходимо указать ожидаемое количество строк в отношениях, а также среднюю и максимальную кратности каждой связи (см. рис. №3.3). Например, ожидается, что персонал компании составит 50 человек, 4 из которых менеджеры, 40 операторов. Компания владеет 500 объектами жилья, на которые заключается 1000 договоров.


Рис. № 3.3. Указание ожидаемой размерности отношений и связи.



При анализе каждой из транзакций очень важно знать не только среднее и максимальное количество ее вызовов в час, но и иметь сведения о тех днях недели и часах суток, когда она обычно выполняется, включая и данные о времени пиковой нагрузки. Например, частота вызова некоторых транзакций может удерживаться на некотором уровне постоянно, но все же она имеет четко выраженный пик нагрузки в последний четверг месяца с 14-00 до 16-00, вызванный подготовкой отчетов. Другие транзакции вообще могут выполняться только в определенные моменты времени, например - по понедельникам с 9-00 до 10-00, что также является пиком нагрузки.

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


Таблица № 3.3. Результаты анализа.


Тран

закция


Актив-ность


День недели


Время суток

Частота вызовов в месяц

Т1. Список всех операторов

Пиковая

-

-

-

Средняя

Понедельник

9-00 – 12-00

1

От отношения

К отношению

Атрибуты

Тип доступа

Частота вызовов в месяц

-

Менеджер

Таб-ном

R(E)

1

Менеджер

Оператор

Таб-ном-мен

Таб-ном


R(E)*



10 - 15

Оператор

Персонал

Таб-ном

*

R(E)

R


Тран

закция


Актив-ность


День недели


Время суток

Частота вызовов в месяц

Т2. Перечень всех договоров конкретного менеджера за конкретный месяц.

Пиковая

Последний четверг месяца

9-00 – 12-00

4

Средняя

-

-

-

От отношения

К отношению

Атрибуты

Тип доступа

Частота вызовов в месяц

-

Персонал

Таб-ном

R(E)

4

Персонал

Договор

Таб-ном

*

R(E)*

R

800 - 1200


Тран

закция


Актив-ность


День недели


Время суток

Частота вызовов в месяц

Т3. Поиск информации об операторе по его ФИО

Пиковая

Последний четверг месяца

15-00 - 16-00

40

Средняя

Понедельник-пятница

Случайным образом

20

От отношения

К отношению

Атрибуты

Тип доступа

Частота вызовов в месяц

-

Персонал

FIO

*

R(E)

R

60



Заключение.

В заключении к курсовому проекту необходимо в краткой форме подвести выводы по проделанной работе, которые могут включать:

Мнение студента о проделанной работе;

Отношение к изученному материалу;

Оценку средств и методов проектирования.


Приложение 1.

Список возможных тем курсового проекта.

  1. Проектирование БД учета продаж новых автомобилей в автосалоне.

  2. Проектирование БД учета продаж подержанных автомобилей.

  3. Проектирование БД учета продаж микроавтобусов.

  4. Проектирование БД учета автомобилей в автостоянке.

  5. Проектирование БД учета ремонта автомобилей в автосервисе.

  6. Проектирование БД учета угнанных автомобилей в ГИБДД.

  7. Проектирование БД учета ДТП.

  8. Проектирование БД учета проката яхт.

  9. Проектирование БД учета продаж видео-, аудио продукции.

  10. Проектирование БД учета автоперевозок грузов.

  11. Проектирование БД учета авиаперевозок грузов.

  12. Проектирование БД учета авиаперевозок пассажиров.

  13. Проектирование БД учета поселения гостей в гостинице.

  14. Проектирование БД учета свободных номеров в гостинице.

  15. Проектирование БД обслуживания посетителей в ресторане.

  16. Проектирование БД обслуживания посетителей в баре.

  17. Проектирование БД учета посетителей в поликлинике.

  18. Проектирование БД учета записей на прием к врачам.

  19. Проектирование БД учета лекарств в аптеке

  20. Проектирование БД учета работ с клиентами в фирме страхования.

  21. Проектирование БД работы с клиентами в фирме недвижимости.

  22. Проектирование БД учета выдачи книг в библиотеке.

  23. Проектирование БД учета поступлений и списаний книг в библиотеке.

  24. Проектирование БД учета денежных переводов.

  25. Проектирование БД учета розничной торговли.

  26. Проектирование БД учета оптовой торговли.

  27. Проектирование БД организации складского хозяйства.

  28. Проектирование БД учета торговли на заказ.

  29. Проектирование БД торговли через Интернет.

  30. Проектирование БД учета продаж театральных билетов.

  31. Проектирование БД сессии в ВУЗе.

  32. Проектирование БД учета продаж продукций цементного завода.

  33. Проектирование БД учета продаж продукций кирпичного завода

  34. Проектирование БД учета продаж продукций мебельной фабрики.

  35. Проектирование БД учета продаж продукций издательства(книги).

  36. Проектирование БД учета продаж продукций кондитерской фабрики

  37. Проектирование БД учета продаж газет и журналов.

  38. Проектирование БД учета вызовов службы скорой помощи

  39. Проектирование БД учета вызовов МЧС.

  40. Проектирование БД учета продаж авиабилетов.

  41. Проектирование БД учета продаж ж/д билетов.

  42. Проектирование БД для мостостроительной компании.

  43. Проектирование БД для дорожно-строительной компании.

  44. Проектирование БД учета заявок клиентов ЖКХ.

  45. Проектирование БД для спортивного общества

  46. Проектирование БД учета клиентов туристической компании.

  47. Проектирование БД учета клиентов коммерческого банка

  48. Проектирование БД для компании по продаже оргтехники.

  49. Проектирование БД для компании по ремонту оргтехники.

  50. Проектирование БД для компании по ремонту телефонов.

  51. Проектирование БД учета клиентов фитнес-клуба.

  52. Проектирование БД учета продаж/услуг почтового отделения

  53. Проектирование БД «авто/моторалли».

  54. Проектирование БД для картинной галереи.

  55. Проектирование БД для ветеринарной клиники.

  56. Проектирование БД для модельного агентства.

  57. Проектирование БД для фотостудии.

  58. Проектирование БД для звукостудии.

  59. Проектирование БД для ломбарда

  60. Проектирование БД для трудовой биржы.

  61. Проектирование БД для бюро находок.

  62. Проектирование БД для Интерпол

  63. Проектирование БД для бюро знакомств.

  64. Проектирование БД для салона сотовой связи.

  65. ….

  66. ….

  67. ….….

Приложение 2.

Пример оформления пояснительной записки к курсовому проекту.

1   2   3

Похожие:

Методические указания к курсовому проекту по дисциплине «базы данных» iconМетодические указания к курсовому проекту по дисциплине «Охрана окружающей среды»
Кая оценка котельной установки [текст]: методические указания к курсовому проекту по дисциплине «Охрана окружающей среды» для студентов...

Методические указания к курсовому проекту по дисциплине «базы данных» iconДерюгин А. А., Иванов А. В. Методические указания к курсовому проекту по дисциплине “Микропроцессорные системы”
Методические указания к курсовому проекту по дисциплине “Микропроцессорные системы”. – М.: Изд-во мэи, 2006. – 17 с

Методические указания к курсовому проекту по дисциплине «базы данных» iconМетодические указания к курсовому проекту по дисциплине «Технология литейного производства»
Методические указания к курсовому проекту по дисциплине «Технология литейного производства» / Владим гос ун-т; сост. А. А. Панфилов....

Методические указания к курсовому проекту по дисциплине «базы данных» iconМетодические указания к курсовому проекту «Вентиляция общественного здания»
Методические указания к курсовому проекту «Вентиляция общественного здания» (зрелищного учреждения) по дисциплине «Вентиляция» для...

Методические указания к курсовому проекту по дисциплине «базы данных» iconМетодические указания к курсовому проекту №1 «Отопление и вентиляция гражданского здания»
Методические указания к курсовому проекту №1 «Отопление и вентиляция гражданского здания» по дисциплине сд. 02. 1 «Системы отопления»...

Методические указания к курсовому проекту по дисциплине «базы данных» iconМетодические указания к курсовому проекту «Вентиляция общественного здания»
Методические указания к курсовому проекту «Вентиляция общественного здания» (общественные здания административного назначения) по...

Методические указания к курсовому проекту по дисциплине «базы данных» iconМетодические указания к курсовому проекту 
Методические указания к курсовому проекту Водоприемные сооружения по курсу Водоснабжение (для студентов 4-5 курсов дневной и...

Методические указания к курсовому проекту по дисциплине «базы данных» iconТребования к проекту
«Базы данных» (специальность 220400 — «Программное обеспечение вычислительной техники и автоматизированных систем») и «Проектирование...

Методические указания к курсовому проекту по дисциплине «базы данных» iconМетодические указания к курсовому проекту по дисциплине «Обеспечение безопасной эксплуатации зданий и сооружений»
Методические указания к курсовому проекту по дисциплине Обеспечение безопасной эксплуатации зданий и

Методические указания к курсовому проекту по дисциплине «базы данных» iconМетодические указания к курсовому проекту «Отопление и вентиляция жилого здания»
Методические указания к курсовому проекту «Отопление и вентиляция жилого здания» для студентов специальности 270112 вв, 270115 –...


Разместите кнопку на своём сайте:
lib.convdocs.org


База данных защищена авторским правом ©lib.convdocs.org 2012
обратиться к администрации
lib.convdocs.org
Главная страница