Компьютерные курсы
| Загрузить архив: | |
| Файл: ref-31308.zip (112kb [zip], Скачиваний: 219) скачать |
Государственное образовательное учреждение
высшего профессионального образования
МОСКОВСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ СВЯЗИ И ИНФОРМАТИКИ
ФАКУЛЬТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
Кафедра Математической Кибернетики
и Информационных Технологий
Разработка базы данных для АСУ
«Компьютерные курсы»
Курсовая работа
студента 4 курса группы ПО0701
Выполнил Мокин Сергей Сергеевич
Научный руководитель
д.ф.-м.н., профессор Воронова Лилия Ивановна
Оценка____________________________
__ декабря 2010 г.
________ Л.И. Воронова
Москва 28.10.2010
Содержание:
Введение……………………………………………………………………………………….3
Глава I. Анализ предметной области объекта автоматизации «Компьютерные курсы»…4
1.1 Системный анализ объекта автоматизации «Компьютерные курсы»………….4
1.2. Обзор информационных технологий, подходящих для разработки ИС компьютерных курсов…………………………………………………………………5
1.3. Обзор продуктов-аналогов……………………………………………………….10
1.4. Требования к разрабатываемой базе данных……………………………………13
Выводы…………………………………………………………………………………13
Глава II. Проектирование базы данных……………………………………………………....14
2.1. Разработка инфологической модели……………………………………………..14
2.2. Обоснование выбора модели данных………………………………………........15
2.3. Логическое проектирование………………………………………………….......24
2.4. Нормализация схемы базы данных……………………………………………….26
Выводы………………………………………………………………………………….28
Глава III. Программная реализация……………………………………………………...........29
3.1. Анализ и выбор СУБД…………………………………………………………….29
3.2. Физическое проектирование базы данных в СУБД………………………..........29
3.3. Разработка представлений………………………………………………………...30
3.4. Разработка форм……………………………………………………………………31
3.5. Разработка отчетов……………………………………………………………........31
3.6. Реализация ограничений…………………………………………………………..32
3.7. Безопасность и контроль…………………………………………………………..32
Выводы………………………………………………………………………………......34
Заключение……………………………………………………………………………………...35
Список литературы……………………………………………………………………………..36
Введение
Актуальность. Автоматизированная система управления или АСУ— это комплекс аппаратных и программных средств, предназначенный для управления различными процессами в рамках некоторого технологического процесса, производства или предприятия. В современном мире АСУ применяются в различных отраслях промышленности, энергетике, транспорте, т.к. затруднительно наладить производство или бизнес без средств его автоматизации. АСУ применяются также для автоматизации социальных сфер деятельности, таких как учебные заведения узкой направленности, т.к.
требуется хранить информацию о преподавателях, учениках и указанных направленностях обучения.
Целью данной работы является построение информационной системы (ИС) «Компьютерные курсы» для автоматизации работы учебного заведения.
Данная ИС позволяет оптимально администрировать данное направление, предоставляя большой выбор предметов в данной области, также с помощью ИС преподаватели всегда будут знать список своих студентов и предмет, который они ведут. Аналогично студенты будут знать, где, когда будут проводиться занятие и кто их преподаватель.
Задачи данной работы:
§провести системный анализ предметной области «Компьютерные курсы»;
§провести обзор информационных технологий, подходящих для разработки информационной системы учебного заведения;
§изучить аналогичные информационные системы данной предметной области;
§описать требования, предъявляемые к разработке данной базы данных;
§разработать инфологическую модель базы данных;
§обосновать выбор модели данных и осуществить логическое проектирование информационной системы;
§нормализовать спроектированную модель и составить схему базы данных;
§осуществить физическое проектирование базы данных выбранной СУБД;
§разработать программное обеспечение, реализующее отчеты и формы для базы данных;
Глава I. Анализ предметной области объекта автоматизации «Компьютерные курсы»
В первой главе курсовой работы проведен системный анализ объекта автоматизации «Компьютерные курсы», в ходе которого приведено описание работы объекта автоматизации и даны ограничения на информацию, содержащуюся в ИС. Также проведены обзор информационных технологий, подходящих для разработки данной ИС, и обзор продуктов-аналогов, позиционирующихся на информационном рынке. В заключении указаны требования, предъявляемые к разрабатываемой БД, и сделан вывод.
1.1 Системный анализ объекта автоматизации «Компьютерные курсы»
Для автоматизации процесса работы со студентами и преподавателями, а также для упрощения доступа к данным, требуется разработать информационную систему для автоматизации зачисления и выпуска студентов на Компьютерные курсы, а также предоставления им преподавателя и аудитории.
Учебное заведение «Компьютерные курсы», которые уже существуют 10 лет, имеет свое здание, с оборудованными, по последним стандартам, аудиториями. За всю историю организации было выпущено несколько тысяч профессионалов, которые обеспечили себе перспективу на хорошее будущее. В данном заведении занятия ведут профессиональные преподаватели, мастера своего направления. Также в учебном заведении числится заведующий, который работает с базой данных.
На направлениях предусмотрена следующая информация:
§ФИО преподавателя;
§номер группы;
§название предмета;
§время начала;
§день недели;
Для каждого преподавателя заводится карточка в отделе кадров, которая содержит информацию о данном человеке:
§ФИО;
§адрес;
§телефон;
§дата рождения;
§должность;
§оклад;
§стаж;
При зачислении студента, в базу также заносятся его личные данные:
§ФИО;
§адрес;
§дата рождения;
§телефон;
§номер группы;
§срок зачисления;
§срок выпуска;
При зачислении студента, также заносится информация о нем в группу:
§номер группы;
§количество студентов в группе;
На группу студентов записывается один преподаватель, один преподаватель может вести несколько предметов в разные дни, также несколько преподавателей могут вести один предмет. За каждым преподавателем закрепляется аудитория, где постоянно проходят занятия.
В аудиториях предусматривается:
§ФИО преподавателя;
§номер аудитории;
§кол-во мест для учащихся;
§кол-во оборудования;
Для данной информационной системы требуется предусмотреть следующие ограничения на информацию:
1.2. Обзор информационных технологий, подходящих для разработки ИС компьютерных курсов
Система управления базами данных (СУБД) — это специализированная программа (чаще комплекс программ), предназначенная для организации и ведения базы данных. В настоящее время существует множество СУБД, подходящих для разработки баз данных к самым разнообразным информационным системам, в том числе и для данной ИС компьютерные курсы.
СУБД можно условно разделить на следующие классы:
·домашние (настольные) СУБД – подходят для использования в домашних условиях и создания небольших баз данных;
·полупрофессиональные СУБД – в основном используются предприятиями малого бизнеса для проектирования баз данных обычных размеров;
·профессиональные СУБД – пригодны для использования в любых бизнес-предприятиях и крупных корпорациях, служат для создания баз данных любых размеров.
MicrosoftAccess является настольной СУБД (система управления базами данных) реляционного типа. Достоинством Access является то, что она имеет очень простой графический интерфейс, который позволяет не только создавать собственную базу данных, но и разрабатывать приложения, используя встроенные средства.
В отличие от других настольных СУБД, Access хранит все данные в одном файле, хотя и распределяет их по разным таблицам, как и положено реляционной СУБД. К этим данным относится не только информация в таблицах, но и другие объекты базы данных, которые будут описаны ниже.
Для выполнения почти всех основных операций Access предлагает большое количество Мастеров (Wizards), которые делают основную работу за пользователя при работе с данными и разработке приложений, помогают избежать рутинных действий и облегчают работу неискушенному в программировании пользователю.
Особенности MS Access, отличающиеся от представления об «идеальной» реляционной СУБД:
Создание многопользовательской БД Access и получение одновременного доступа нескольких пользователей к общей базе данных возможно в локальной одноранговой сети или в сети с файловым сервером.
Сеть обеспечивает аппаратную и программную поддержку обмена даннымимежду компьютерами.
Access следит за разграничением доступа разных пользователей к БД и обеспечивает защиту данных. При одновременной работе. Так как Access не является клиент серверной СУБД, возможности его по обеспечению многопользовательской работы несколько ограничены. Обычно для доступа к данным по сети с нескольких рабочих станций, файл БД Access (с расширением *.mdb) выкладывается на файловый сервер. При этом обработка данных ведется в основном на клиенте – там, где запущено приложение, в силу принципов организации файловых СУБД. Этот фактор ограничивает использование Access для обеспечения работы множества пользователей (более 15-20) и при большом количестве данных в таблицах, так как многократно возрастает нагрузка не сеть.
В плане поддержки целостности данных Access отвечает только моделям БД небольшой и средней сложности. В нем отсутствуют такие средства как триггеры и хранимые процедуры, что заставляет разработчиков возлагать поддержание бизнес логики БД на клиентскую программу.
В отношении защиты информации и разграничения доступа Access не имеет надежных стандартных средств. В стандартные способы защиты входит защита с использованием пароля БД и защита с использованием пароля пользователя. Снятие такой защиты не представляет сложности для специалиста.
Однако, при известных недостатках MSAccess обладает большим количеством преимуществ по сравнению с системами подобного класса.
В первую очередь можно отметить распространенность, которая обусловлена тем, что Access является продуктом компании Microsoft, программное обеспечение и операционные системы которой использует большая часть пользователей персональных компьютеров. MSAccess полностью совместим с операционной системой Windows, постоянно обновляется производителем, поддерживает множество языков.
В целом MSAccess предоставляет большое количество возможностей за сравнительно небольшую стоимость. Также необходимо отметить ориентированность на пользователя с разной профессиональной подготовкой, что выражается в наличии большого количества вспомогательных средств (Мастеров, как уже отмечалось), развитую систему справки и понятный интерфейс. Эти средства облегчают проектирование, создание БД и выборку данных из нее.
MSAccess предоставляет в распоряжение непрограммирующему пользователю разнообразные диалоговые средства, которые позволяют ему создавать приложения не прибегая к разработке запросов на языке SQL или к программированию макросов или модулей на языке VBA.
Access обладает широкими возможностями по импорту/экспорту данных в различные форматы, от таблиц Excel и текстовых файлов, до практически любой серверной СУБД через механизм ODBC.
Еще одно немаловажное преимущество MSAccess заключается в развитых встроенных средствах разработки приложений. Большинство приложений, распространяемых среди пользователей, содержит тот или иной объем кода VBA (Visual Basic for Applications). Поскольку VBA является единственным средством для выполнения многих стандартных задач в Access (работа с переменными, построение команд SQL во время работы программы, обработка ошибок, использование Windows API ит.д.), для создания более-менее сложных приложений необходимо его знание и знание объектной модели MSAccess.
Одним из средств программирования в Accessявляется язык макрокоманд. Программы, созданные на этом языке, называются макросами и позволяют легко связывать отдельные действия, реализуемые с помощью форм, запросов, отчетов. Макросы управляются событиями, которые вызываются действиями пользователями при диалоговой работе с данными через формы или системными событиями.
Полупрофессиональные СУБД
SQLite — встраиваемый движок баз данных. В 2005 году проект получил награду Google-O’Reilly Open Source Awards.
Слово «встраиваемый» означает, что SQLite не использует парадигму клиент-сервер, то есть движок SQLite не является отдельно работающим процессом, с которым взаимодействует программа, а предоставляет библиотеку, с которой программа компонуется и движок становится составной частью программы. Таким образом, в качестве протокола обмена используются вызовы функций (API) библиотеки SQLite. Такой подход уменьшает накладные расходы, время отклика и упрощает программу. SQLite хранит всю базу данных (включая определения, таблицы, индексы и данные) в единственном стандартном файле на том компьютере, на котором исполняется программа. Простота реализации достигается за счёт того, что перед началом исполнения транзакции весь файл, хранящий базу данных, блокируется; ACID-функции достигаются в том числе за счёт создания файла-журнала.
Несколько процессов или потоков могут одновременно без каких-либо проблем читать данные из одной базы. Запись в базу можно осуществить только в том случае, если никаких других запросов в данный момент не обслуживается; в противном случае попытка записи оканчивается неудачей, и в программу возвращается код ошибки. Другим вариантом развития событий является автоматическое повторение попыток записи в течение заданного интервала времени.
В комплекте поставки идет также функциональная клиентская часть в виде исполняемого файла sqlite3, с помощью которого демонстрируется реализация функций основной библиотеки. Клиентская часть работает из командной строки, позволяет обращаться к файлу БД на основе типовых функций ОС.
Благодаря архитектуре движка возможно использовать Sqlite как на встраиваемых (embedded) системах, так и на выделенных машинах с гигабайтными массивами данных.
Технологии, поддерживающие SQLite. Языки программирования.
Сама библиотека SQLite написана на C; существует большое количество привязок к другим языкам программирования, в том числе C++, Java, .NET, Python, Perl, PHP, Tcl (средства для работы с Tcl включены в комплект поставки SQLite), Ruby, Haskell, Scheme, Smalltalk и Lua, а также ко многим другим. Полный список существующих средств можно найти на странице проекта.
Web-инструментарии.
В ряде инструментариев присутствует возможность использования SQLite как базы данных, например:
§Adobe Flex
§PHP
§Ruby on Rails
§1C Работа в 1С-Предприятии 7.7 с базами данных SQLite
§SQLite Manager — add-on для Firefox предлагает визуальный интерфейс для работы с SQLite
MySQL является собственностью компании Sun Microsystems, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор. Помимо этого компания MySQL AB разрабатывает функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.
MySQL является решением для малых и средних приложений. Входит в LAMP. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы.
Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.
MySQL портирована на большое количество платформ:AIX, BSDi, FreeBSD, HP-UX, GNU/Linux, MacOSX, NetBSD, OpenBSD, OS/2 Warp, SGIIRIX, Solaris, SunOS, SCOOpenServer, SCOUnixWare, Tru64, Windows 95, Windows 98, WindowsNT, Windows 2000, WindowsXP, WindowsServer 2003, WinCE, WindowsVista и Windows 7. Существует также порт MySQLна OpenVMS. Важно отметить, что компания MySQLAB предоставляет для свободной загрузки не только исходные коды СУБД, но и откомпилированные и оптимизированные под конкретные операционные системы готовые исполняемые модули.
MySQL имеет API для языков Delphi, C, C++, Эйфель, Java, Лисп, Perl, PHP, Python, Ruby, Smalltalk и Tcl, библиотеки для языков платформы .NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.
Cистема управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для небольших и средних по размеру баз данных, и в последние 5 лет — для крупных баз данных масштаба предприятия, конкурирует с другими СУБД в этом сегменте рынка.
Функциональность.
MicrosoftSQLServer в качестве языка запросов использует версию SQL, получившую название Transact-SQL (сокращённо T-SQL), являющуюся реализацией SQL-92 (стандарт ISO для SQL) с множественными расширениями. T-SQL позволяет использовать дополнительный синтаксис для хранимых процедур и обеспечивает поддержку транзакций (взаимодействие базы данных с управляющим приложением). MicrosoftSQLServer и SybaseASE для взаимодействия с сетью используют протокол уровня приложения под названием TabularDataStream (TDS, протокол передачи табличных данных). Протокол TDS также реализован в проекте FreeTDS с целью обеспечить различным приложениям возможность взаимодействия с базами данных MicrosoftSQLServer и Sybase.
MicrosoftSQLServer также поддерживает OpenDatabaseConnectivity(ODBC) — интерфейс взаимодействия приложений с СУБД. Версия SQLServer 2005 обеспечивает возможность подключения пользователей через веб-сервисы, использующие протокол SOAP. Это позволяет клиентским программам, не предназначенным для Windows, кроссплатформенно соединяться с SQLServer. Microsoft также выпустила сертифицированный драйвер JDBC, позволяющий приложениям под управлением Java (таким как BEA и IBMWebSphere) соединяться с MicrosoftSQLServer 2000 и 2005.
SQLServer поддерживает зеркалирование и кластеризацию баз данных. Кластер сервера SQL — это совокупность одинаково конфигурированных серверов, такая схема помогает распределить рабочую нагрузку между несколькими серверами. Все сервера имеют одно виртуальное имя, и данные распределяются по IP адресам машин кластера в течение рабочего цикла. Также в случае отказа или сбоя на одном из серверов кластера доступен автоматический перенос нагрузки на другой сервер.
SQLServer поддерживает избыточное дублирование данных по трем сценариям:
§Снимок: Производится «снимок» базы данных, который сервер отправляет получателям.
§История изменений: Все изменения базы данных непрерывно передаются пользователям.
§Синхронизация с другими серверами: Базы данных нескольких серверов синхронизируются между собой. Изменения всех баз данных происходят независимо друг от друга на каждом сервере, а при синхронизации происходит сверка данных. Данный тип дублирования предусматривает возможность разрешения противоречий между БД.
В SQLServer 2005 встроена поддержка .NETFramework. Благодаря этому, хранимые процедуры БД могут быть написаны на любом языке платформы .NET, используя полный набор библиотек, доступных для .NETFramework, включая CommonTypeSystem (система обращения с типами данных в Microsoft .NETFramework). Однако, в отличие от других процессов, .NETFramework, будучи базисной системой для SQLServer 2005, выделяет дополнительную память и выстраивает средства управления SQLServer вместо того, чтобы использовать встроенные средства Windows. Это повышает производительность в сравнении с общими алгоритмами Windows, так как алгоритмы распределения ресурсов специально настроены для использования в структурах SQLServer.
Разработка приложений
Microsoft и другие компании производят большое число программных средств разработки, позволяющих разрабатывать бизнес-приложения с использованием баз данных MicrosoftSQLServer. MicrosoftSQLServer 2005 включает в себя также CommonLanguageRuntime (CLR) Microsoft .NET, позволяющий реализовывать хранимые процедуры и различные функции приложениям, разработанным на языках платформы .NET (например, VB.NET или C#). Предыдущие версии средств разработки Microsoft использовали только API для получения функционального доступа к MicrosoftSQLServer.
1.3. Обзор продуктов-аналогов
В настоящее время на рынке информационных систем позиционируются продукты, имеющие аналогичные с разрабатываемой ИС объекты автоматизации: колледж, учебное заведение, ВУЗ. Рассмотрим подробнее данные продукты и приведем их основные особенности.
АСУ "Колледж"
Концепция АСУ УП «Колледж» была предложена в конце 90-х годов, примерная работоспособная версия создана в 2000 году, а реально работающая система появилась в 2001 году. С 2002 года в ТПК в полном режиме работают и продолжают развиваться модули: «Отделение», «Отдел кадров», «Учебная часть», «Библиотека», «Тестирование».
АРМ “Отдел кадров”
предназначен для автоматизации процесса учета сотрудников колледжа и получения различной статистической информации о количестве, положении сотрудников согласно штатному расписанию. Полностью автоматизирован процесс перемещений по занимаемым должностям.
АРМ “Учебная часть”
- это мощный инструмент контроля за ходом учебного процесса. При помощи этого программного обеспечения можно получить достоверную картину по количеству проведенных часов данным преподавателем, в данной группе (это формы №2 и №3), графики учебного процесса конкретных групп. Кроме этого, можно получать списки ежедневного изменения расписания занятий и другие документы. Для корректировки учебного процесса существует раздел «Замены», в котором программа помогает подобрать предмет и преподавателя для проведения занятий в группе с учетом вычитанных часов и учебного плана.
АРМ “Отделение”
предназначен для автоматизированного учета студентов колледжа. Предусмотрена автоматическая сортировка списков студентов по заданному шаблону поиска, учет оплаты за обучение, учет перемещений из группы в группу. Предусмотрен вывод на печать семестровой ведомости списка группы, списков студентов группы для журналов, печать справок для военкоматов, печать выписок к дипломам.
АРМ “Библиотека”
позволяет систематизировать ведение книжного фонда. На его основе реализован поиск нужной книги по различным критериям с любого компьютера колледжа. Активно идет разработка реализации повседневного контроля “движения” фонда – учет выдачи книг.
АРМ “Тестирование”
помогает строить картину успеваемости в разрезе предметов, преподавателей, учебных групп. В общем доступе находятся множество унифицированных по формату и интерфейсу тестов по различным предметам. Тесты имеют гибкую систему настройки. Любой студент может проверить свои знания по любому предмету. В режиме тренировки программа не ограничивает тестируемого по времени и сообщает оценку, не занося ее в отчет. В режиме проверки результаты тестов заносятся в общую базу данных для анализа и обработки. При этом данные студента (фамилия, имя, группа) однозначно соответствуют его сетевому имени, т.е. для работы достаточно зарегистрироваться в сети и запустить тест – все остальное система “узнает” сама. Таким образом, в любой учебный день можно осуществлять мониторинг знаний по конкретному предмету любой группы, так как преподаватель может ограничить количество выдаваемых вопросов в соответствии с пройденным на данный момент материалом.
АСУ «Учебное заведение»
Программный комплекс “Автоматизированная система управления учебным заведением” представляет собой множество связанных между собой программ, обеспечивающих управление вузом в едином информационном пространстве, и включает в себя модули, работающие в среде Windows (учебный модуль, деканат, абитуриент, методический отдел, отдел кадров и т.д.) и WEB портал (отображение расписания занятий, успеваемости, учебных планов, начислений оплат за общежитие, контроль оплат за обучение и общежитие, тестирование студентов, запись студентов на изучение дисциплин т.д.). Вся информация хранится в одной общей базе данных.
Основными отличительными характеристиками комплекса, является наличие инструмента самостоятельного создания различных печатных форм и статистических экранных форм, что делает автоматизированную систему управления учебным заведением почти не зависимой от фирмы разработчика. Существующие функциональные возможности, как показала практика и анализ, позволяют охватить фактически все индивидуальные особенности вузов без программной доработки кода. Комплекс также позволяет создавать и учитывать индивидуальные траектории обучения студентов, в том числе через Internet.
Информация представленная на сайте позволяет:
• просмотреть перечень решаемых задач и основные функциональные возможности;
• получить доступ к библиотеке печатных форм, а также просмотреть примеры сформированных форм (раздел находится на этапе наполнения);
• просмотреть список (историю) изменений и добавлений в различных модулях комплекса, а также скачать последнюю версию программы (доступно только зарегистрированным пользователям);
• скачать инструкцию пользователя с добавлениями и изменениями (доступно только зарегистрированным пользователям).
АСУ «ВУЗ»
Программный продукт автоматизированной системы управления вузом (АСУ ВУЗ) «Universys WS 3.5» является программной платформой для создания и функционирования проектов АСУ ВУЗ для образовательных учреждений и организаций.
Проекты, созданные на его базе состоят из следующих типовых модулей - виртуальных разделов:
ПП «Universys Web Server» представляет собой программный комплекс, состоящий из базы данных (БД) и программного обеспечения Web - интерфейса системы.
Проекты, построенные на базе ПП «Universys Web Server» позволяют автоматизировать следующие основные деловые процессы образовательного учреждения:
Проекты на базе ПО АСУ ВУЗ "Universys Web Server" становятся особенно полезными в случаях, если у образовательного учреждения:
1.4. Требования к разрабатываемой базе данных
Разрабатываемая база данных должна полностью удовлетворять потребности всех её пользователей. Рассмотрим, какие группы пользователей могут работать с базой данных, и какие задачи они должны выполнять.
С данной базой данных могут работать следующие группы пользователей:
При работе с базой данных заведующий может выполнять следующие задачи:
При работе с базой данных преподаватель может выполнять следующие задачи:
При работе с базой данных студент может:
Выводы
В данной главе проведен анализ предметной области объекта автоматизации «Компьютерные курсы», в ходе которого перечислены должности работников учебного заведения и ограничения, накладываемые на информацию, содержащуюся в информационной системе.
В ходе обзора информационных технологий перечислены классы СУБД, приведены примеры для каждого класса и определены достоинства и недостатки следующих СУБД: MicrosoftAccess, SQLite, MySQL, MicrosoftSQLServer.
Рассмотрены продукты-аналоги на рынке информационных систем(АСУ «КОЛЛЕДЖ», АСУ «Учебное заведение», АСУ «ВУЗ») и даны описания данных систем.
В заключении главы указаны требования к разрабатываемой базе данных со стороны каждой из групп пользователей и перечислены выполняемые этими пользователями задачи.
Таким образом, полностью выполнен анализ предметной области и осуществлена подготовка к этапу проектирования базы данных.
Глава II. Проектирование базы данных
Во второй главе курсовой работы проведено проектирование разрабатываемой информационной системы на инфологическом уровне, при этом выделены сущности и построена инфологическая модель предметной области. Затем приведены достоинства и недостатки каждой из существующих моделей данных, обоснован выбор реляционной модели и построена даталогическая модель ИС. А также нормализована спроектированная модель и построена схема базы данных. В заключении приведены выводы по данной главе.
2.1. Разработка инфологической модели
Целью инфологического проектирования является создание структурированной информационной модели предметной области, для которой будет разрабатываться база данных. При проектировании на инфологическом уровне создается информационно-логическая модель, которая должна отвечать следующим требованиям:
Суть инфологического моделирования состоит в выделении сущностей(информационных объектов предметной области), которые подлежат хранению в базе данных, а также в определении характеристик объектов и взаимосвязей между ними.
Для информационной системы «Компьютерные курсы» на основе проведенного системного анализа предметной области выделены следующие сущности:
Исходя из приведенных выше сущностей, построена инфологическая модель предметной области, которая представлена на рисунке 1.
Рис.1 Инфологическая модель предметной области
2.2. Обоснование выбора модели данных
Под даталогической моделью понимается модель, отражающая логические взаимосвязи между элементами данных безотносительно их содержания и физические организации. При этом даталогическая модель разрабатывается с учетом конкретной реализации СУБД, также с учетом специфики конкретной предметной области на основе ее инфологической модели.
Существуют несколько разновидностей даталогических моделей данных:
Чтобы определить, какая модель лучше всего подходит для проектирования разрабатываемой ИС, рассмотрим подробней каждую разновидность.
Иерархическая модель данных
Структура данных.
Организация данных в СУБД иерархического типа определяется в терминах:
Корневая запись каждого дерева обязательно должна содержать ключ с уникальным значением. Ключи некорневых записей должны иметь уникальное значение только в рамках группового отношения. Каждая запись идентифицируется полным сцепленным ключом, под которым понимается совокупность ключей всех записей от корневой по иерархическому пути. При графическом изображении групповые отношения изображают дугами ориентированного графа, а типы записей – вершинами(диаграмма Бахмана).
Для групповых отношений в иерархической модели обеспечивается автоматический режим включения и фиксированное членство. Это означает, что для запоминания любой некорневой записи в БД должна существовать ее родительская запись. При удалении родительской записи автоматически удаляются все подчиненные.
У иерархических БД имеются следующие недостатки:
Операции над данными, определенные в иерархической модели:
oИзвлечь корневую запись по ключевому значению, допускается также последовательный просмотр корневых записей;
oИзвлечь следующую запись(следующая запись извлекается в порядке левостороннего обхода дерева);
В операции ИЗВЛЕЧЬ допускается задание условий выборки(например, извлечь сотрудников с окладом более 1 тысячи рублей).
Как видим, все операции изменения применяются только к одной «текущей» записи, которая предварительно извлечена из базы данных. Такой подход к манипулированию данных получил название «навигационного».
Ограничения целостности.
Поддерживается только целостность связей между владельцами и членами группового отношения(никакой потомок не может существовать без предка). Как уже отмечалось, не обеспечивается автоматическое поддерживание соответствия парных записей, входящих в различные иерархии.
На разработку этого стандарта большое влияние оказал американский ученый Ч.Бахман. Основные принципы сетевой модели данных разработаны в середине 60-х годов, эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных (COnference on DAta SYstem Languages) CODASYL (1971 г.).
Сетевая модель данных определяется в тех же терминах, что и иерархическая. Она состоит из множества записей, которые могут быть владельцами или членами групповых отношений. Связь между записью-владельцем и записью-членом также имеет вид 1:N.
Основное различие этих моделей состоит в том, что в сетевой модели запись может быть членом более чем одного группового отношения. Согласно этой модели каждое групповое отношение именуется и проводится различие между его типом и экземпляром. Тип группового отношения задается его именем и определяет свойства общие для всех экземпляров данного типа. Экземпляр группового отношения представляется записью-владельцем и множеством (возможно пустым) подчиненных записей. При этом имеется следующее ограничение: экземпляр записи не может быть членом двух экземпляров групповых отношений одного типа.
Каждый экземпляр группового отношения характеризуется следующими признаками:
§способ упорядочения подчиненных записей:
oпроизвольный,
oхронологический(очередь),
oобратный хронологический(стек),
oсортированный.
Если запись объявлена подчиненной в нескольких групповых отношениях, то в каждом из них может быть назначен свой способ упорядочивания.
§режим включения подчиненных записей:
oавтоматический - невозможно занести в БД запись без того, чтобы она была сразу же закреплена за неким владельцем;
oручной - позволяет запомнить в БД подчиненную запись и не включать ее немедленно в экземпляр группового отношения. Эта операция позже инициируется пользователем;
§режим исключения Принято выделять три класса членства подчиненных записей в групповых отношениях:
Как и в иерархической модели обеспечивается только поддержание целостности по ссылкам (владелец отношения - член отношения).
Реляционная модель предложена сотрудником компании IBM Е.Ф.Коддом в 1970 г. (русский перевод статьи, в которой она впервые описана опубликован в журнале "СУБД" N 1 за 1995 г.). В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.
В реляционной модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой. В упомянутой статье Е.Ф.Кодда утверждается, что "реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления". Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название "реляционная" происходит от английского relation - "отношение").
Перейдем к рассмотрению структурной части реляционной модели данных. Прежде всего необходимо дать несколько определений.
Определения:
(не обязательно различных) декартовым произведением 
называется множество произведений вида: 
, где 
называется подмножество декартова произведения . При этом:
называются доменами отношения
называются кортежами
Пример: на множестве С могут быть определены отношения R1 (a1*b1, a3*b2) или R2 (a1*b1, a2*b1, a1*b2)
Отношения удобно представлять в виде таблиц. На рис. 2 представлена таблица (отношение степени 5), содержащая некоторые сведения о работниках гипотетического предприятия. Строки таблицы соответствуют кортежам. Каждая строка фактически представляет собой описание одного объекта реального мира (в данном случае работника), характеристики которого содержатся в столбцах. Можно провести аналогию между элементами реляционной модели данных и элементами модели "сущность-связь". Реляционные отношения соответствуют наборам сущностей, а кортежи - сущностям. Поэтому, также как и в модели "сущность-связь" столбцы в таблице, представляющей реляционное отношение, называют атрибутами.
Рис.2. Основные компоненты реляционного отношения.
Каждый атрибут определен на домене, поэтому домен можно рассматривать как множество допустимых значений данного атрибута.
Несколько атрибутов одного отношения и даже атрибуты разных отношений могут быть определены на одном и том же домене. В примере, показанном на рис.2 атрибуты "Оклад" и "Премия" определены на домене "Деньги". Поэтому, понятие домена имеет семантическую нагрузку: данные можно считать сравнимыми только тогда, когда они относятся к одному домену. Таким образом, в рассматриваемом нами примере сравнение атрибутов "Табельный номер" и "Оклад" является семантически некорректным, хотя они и содержат данные одного типа.
Именованное множество пар "имя атрибута - имя домена" называется схемой отношения. Мощность этого множества - называют степенью или "арностью" отношения. Набор именованных схем отношений представляет из себя схему базы данных.
Атрибут, значение которого однозначно идентифицирует кортежи, называется ключевым (или просто ключом). В нашем случае ключом является атрибут "Табельный номер", поскольку его значение уникально для каждого работника предприятия. Если кортежи идентифицируются только сцеплением значений нескольких атрибутов, то говорят, что отношение имеет составной ключ.
Отношение может содержать несколько ключей. Всегда один из ключей объявляется первичным, его значения не могут обновляться. Все остальные ключи отношения называются возможными ключами.
В отличие от иерархической и сетевой моделей данных в реляционной отсутствует понятие группового отношения. Для отражения ассоциаций между кортежами разных отношений используется дублирование их ключей. Рассмотрим пример базы данных (см. рис.3), содержащей сведения о подразделениях предприятия и работающих в них сотрудниках, применительно к реляционной модели будет иметь вид:
Рис.3. База данных о подразделениях и сотрудниках предприятия.
Например, связь между отношениями ОТДЕЛ и СОТРУДНИК создается путем копирования первичного ключа "Номер_отдела" из первого отношения во второе.
Таким образом:
Атрибуты, представляющие собой копии ключей других отношений, называются внешними ключами.
Объектно-ориентированная модель данных
Основные трудности объектно-ориентированного моделирования данных проистекают из того, что такого развитого математического аппарата, на который могла бы опираться общая объектно-ориентированная модель данных, не существует. В большой степени, поэтому до сих пор нет базовой объектно-ориентированной модели. С другой стороны, некоторые авторы утверждают, что общая объектно-ориентированная модель данных в классическом смысле и не может быть определена по причине непригодности классического понятия модели данных к парадигме объектной ориентированности.
Один из наиболее известных теоретиков в области моделей данных Беери предлагает в общих чертах формальную основу ООБД, далеко не полную и не являющуюся моделью данных в традиционном смысле, но позволяющую исследователям и разработчикам систем ООБД по крайней мере говорить на одном языке (если, конечно, предложения Беери будут развиты и получат поддержку). Независимо от дальнейшей судьбы этих предложений мы считаем полезным кратко их пересказать.
Имеется множество других публикаций, относящихся к теме объектно-ориентированных моделей данных, но они либо затрагивают достаточно частные вопросы, либо используют слишком серьезный для этого обзора математический аппарат (например, некоторые авторы определяют объектно-ориентированную модель данных на основе теории категорий).
Для иллюстрации текущего положения дел мы кратко рассмотрим особенности конкретной модели данных, применяемой в объектно-ориентированной СУБД O2 (это, конечно, тоже не модель данных в классическом смысле).
В O2 поддерживаются объекты и значения:
Возможны два вида организации данных: классы, экземплярами которых являются объекты, инкапсулирующие данные и поведение, и типы, экземплярами которых являются значения. Каждому классу сопоставляется тип, описывающий структуру экземпляров класса. Типы определяются рекурсивно на основе атомарных типов и ранее определенных типов и классов с применением конструкторов. Поведенческая сторона класса определяется набором методов.
Объекты и значения могут быть именованными. С именованием объекта или значения связана долговременность его хранения (persistency): любые именованные объекты или значения долговременны; любые объект или значение, входящие как часть в другой именованный объект или значение, долговременны.
С помощью специального указания, задаваемого при определении класса, можно добиться долговременности хранения любого объекта этого класса. В этом случае система автоматически порождает значение-множество, имя которого совпадает с именем класса. В этом множестве гарантированно содержатся все объекты данного класса.
Метод - программный код, привязанный к конкретному классу и применимый к объектам этого класса. Определение метода в O2 производится в два этапа. Сначала объявляется сигнатура метода, т.е. его имя, класс, типы или классы аргументов и тип или класс результата. Методы могут быть публичными (доступными из объектов других классов) или приватными (доступными только внутри данного класса). На втором этапе определяется реализация класса на одном из языков программирования O2 (подробнее языки обсуждаются в следующем разделе нашего обзора).
В модели O2 поддерживается множественное наследование классов на основе отношения супертип/подтип. В подклассе допускается добавление и/или переопределение атрибутов и методов. Возможные при множественном наследовании двусмысленности (по именованию атрибутов и методов) разрешаются либо путем переименования, либо путем явного указания источника наследования. Объект подкласса является объектом каждого суперкласса, на основе которого порожден данный подкласс.
Поддерживается предопределенный класс "Оbject", являющийся корнем решетки классов; любой другой класс является неявным наследником класса "Object" и наследует предопределенные методы ("is_same", "is_value_equal" и т.д.).
Специфической особенностью модели O2 является возможность объявления дополнительных "исключительных" атрибутов и методов для именованных объектов. Это означает, что конкретный именованный объект-представитель класса может обладать типом, являющимся подтипом типа класса. Конечно, с такими атрибутами не работают стандартные методы класса, но специально для именованного объекта могут быть определены дополнительные (или переопределены стандартные) методы, для которых дополнительные атрибуты уже доступны. Подчеркивается, что дополнительные атрибуты и методы привязываются не к конкретному объекту, а к имени, за которым в разные моменты времени могут стоять вообще говоря разные объекты. Для реализации исключительных атрибутов и методов требуется развитие техники позднего связывания.
2.3. Логическое проектирование
Для логического проектирования выбрана реляционная модель данных, т.к. она наиболее полно соответствует требованиям, предъявленным к разрабатываемой информационной системе:
В реляционной базе данных даталогическое проектирование приводит к разработке корректной схемы базы данных, т.е. такой схемы, в которой отсутствуют нежелательные зависимости между атрибутами. При этом можно использовать процесс проектирования с помощью декомпозиции, т.е. последовательно нормализовывать схему отношений, тем самым накладывая ограничения и избавляясь от нежелательных зависимостей между атрибутами.
Чтобы перейти к реляционной модели и построить даталогическую модель ИС, каждой сущности из инфологической модели данных поставим в соответствие отношение реляционной модели. В таком случае, каждый атрибут сущности становится атрибутом соответствующего ему отношения. Также укажем каждому атрибуту тип данных и признак обязательности. Обозначим первичные и внешние ключи. После всего проведем нормализацию получившейся модели данных.
Приведем список атрибутов для каждого отношения в схеме базы данных:
Рис. 4 Схема базы данных до нормализации
2.4. Нормализация схемы базы данных
Нормальная форма — свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение.
Нормализация – это процесс преобразования базы данных к виду, отвечающему нормальным формам. Нормализация предназначена для приведения структуры базы данных к виду, обеспечивающему минимальную избыточность, то есть нормализация не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение объёма БД. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации.
Устранение избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов).
Таблица находится в первой нормальной форме, если каждый её атрибут атомарен, то есть может содержать только одно значение. Таким образом, не существует 1NF таблицы, в полях которых могут храниться списки значений. Для приведения таблицы к 1NF обычно требуется разбить таблицу на несколько отдельных таблиц.
Отношение находится во второй нормальной форме (2NF), если она находится в первой нормальной форме, и при этом любой её атрибут, не входящий в состав первичного ключа, функционально полно зависит от первичного ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего первичного составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов (частей). Или другими словами: в 2NF нет неключевых атрибутов, зависящих от части составного ключа.
Для исходной схемы базы данных, полученной в предыдущем разделе и находящейся в первой нормальной форме, нормализация ко второй нормальной форме не требуется, т.к. в схеме отсутствуют отношения, имеющие составной первичный ключ. Т.е. исходная схема базы данных уже находится во второй нормальной форме.
Отношение находится в третьей нормальной форме (3NF), если она находится во второй нормальной форме 2NF и при этом любой ее неключевой атрибут зависит только от первичного ключа (Primary key, PK). Таким образом, отношение находится в 3NF тогда и только тогда, когда оно находится во 2NF и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых.
В схеме базы данных разрабатываемой ИС, приведенной ко второй нормальной форме, присутствует транзитивная зависимость между атрибутами в отношении Аудитория: атрибут Номер аудитории зависит от внешнего ключа ФИО преподавателя, а атрибуты Кол-во мест и кол-во оборудования зависят от неключевого атрибута Номер аудитории.
Таким образом, нормализацией к третьей нормальной форме в данном случае представляет собой вынесение атрибутов Номер аудитории, кол-во мест и кол-во оборудования в отдельное отношение Аудитория. Отсюда получаем следующие изменения в списке атрибутов:
Результирующее отношение, находящееся в третьей нормальной форме, приведено на рисунке 5.
Рис. 5 Нормализованная база данных
Выводы
Во второй главе курсовой работы приведена разработка информационно-логической модели. Выделены сущности, дано их описание и построена инфологическая модель предметной области.
Далее в ходе обоснования выбора модели данных описаны существующие модели данных (иерархическая, сетевая, реляционная, объектно-ориентированная), указаны их достоинства и недостатки, и сделан выбор в пользу реляционной модели.
Затем на основании инфологической модели построена даталогическая модель данных, дан список атрибутов ее отношений и проведена нормализация до третьей нормальной формы. Таким образом, завершено проектирование базы данных и получена вся информация, необходимая для реализации проектируемой инфомационной системы в одной из реляционных СУБД.
Глава III. Программная реализация
В данной главе проведен анализ и выбрана СУБД, в которой осуществлено физическое проектирование базы данных. Также указаны особенности разработки представлений, форм и отчетов, методы реализации ограничений и способы обеспечения безопасности информации, хранимой в базе данных. В конце главы приведены выводы.
3.1. Анализ и выбор СУБД
Для программной реализации информационной системы выбрана СУБД MicrosoftSQLServer 2005 ExpressEdition. Эта СУБД бесплатна для некоммерческого использования, имеет все средства для разработки реляционной базы данных, использует язык Transact-SQL, поддерживает проверочные ограничения(constraints), представления, процедуры и триггера. Данная СУБД более подробно описана в разделе 1.2.
Для отображения отчетов и форм написана программа на языке C# на платформе .NETFramework 3.5, используя технологию LINQ для доступа к базе данных Microsoft SQL Server.
C# - объектно-ориентированный язык программирования. Разработан в 1998 – 2001 годах группой инженеров под руководством Андерса Хейлсберга в компании Microsoftкак основной язык разработки приложений для платформы Microsoft .NET. Компилятор с C# входит в стандартную установку самой .NET, поэтому программы на нем можно создавать и компилировать даже без инструментальных средств, вроде VisualStudio.
C# относиться к семье языков с С-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java. Язык имеет статическую типизацию, поддерживает полиморфизм, перегрузку операторов(в том числе операторов явного и неявного приведения типа), делегаты, атрибуты, события, свойства, обобщенные типы и методы, итераторы, анонимные функции с поддержкой замыканий, LINQ, исключения, комментарии в формате XML.
LINQ(LanguageIntegratedQuery) – проект Microsoftпо добавлению синтаксиса языка запросов, напоминающего SQL, в языки программирования платформы .NETFramework.
Изначально поддерживая механизм запросов для коллекций объектов в памяти, реляционных баз данных и данных в формате XML, LINQобладает расширяемой архитектурой, которая позволяет сторонним разработчикам реализовать доступ к их хранилищам данных через механизм LINQ. Для этого необходимо реализовать стандартные операторы запросов, используя методы расширения, или реализовать интерфейс IQueryable, позволяющий разбирать дерево выражения во время выполнения, транслируя его в свой язык запросов.
3.2. Физическое проектирование базы данных в СУБД.
При физическом проектировании базы данных созданы следующие таблицы:
Схема разработанной в СУБД базы данных приведена на рисунке 6.
Рис.6 Схема базы данных в СУБДMicrosoftSQLServer
Для автоматизации обработки в базе данных разработаны процедуры и триггеры. Основным назначением процедур в данной базу данных является упрощение процесса добавления записей. Ниже приведены функциональные особенности для каждой из них:
Триггеры в базе данных служат для реализации некоторых ограничений, которые невозможно организовать иным образом. Ниже приведено назначение каждого из триггеров:
3.3. Разработка представлений
На основании типовых запросов, приведенных в первой главе, и для отображения специфической информации, получаемой из нескольких таблиц, в удобной для пользователей форме, разработано несколько представлений, описание которых приведено ниже:
3.4. Разработка форм
Для упрощения добавления новых данных в базу данных для пользователей информационной системы созданы следующие формы:
3.5. Разработка отчетов
Для отображения представлений (раздел 3.3), созданных на основании типовых запросов, описанных в первой главе, в удобной для печати форме, разработаны следующие запросы:
3.6. Реализация ограничений
Для реализации ограничений на информацию, описанных в разделе 1.1, использованы триггеры и проверочные ограничения. Триггеры в данной базе служат для реализации тех ограничений, которые невозможно организовать другим образом:
Более подробно о триггерах в разделе 3.2. Для реализации всех остальных ограничений на информацию использовались следующие проверочные ограничения:
3.7. Безопасность и контроль
Для безопасного хранения информации в базе данных используются средства, предоставляемые СУБД MicrosoftSQLServer 2005, такие как:
·авторизация и аутентификация пользователей:
SQL Server 2005 поддерживает два режима аутентификации: с помощью Windows и с помощью SQL Server. Первый режим позволяет реализовать решение, основанное на однократной регистрации пользователя и едином пароле при доступе к различным приложениям (Single SignOn solution, SSO). Подобное решение упрощает работу пользователей, избавляя их от необходимости запоминания множества паролей и тем самым снижая риск их небезопасного хранения. Кроме того, данный режим позволяет использовать средства безопасности, предоставляемые операционной системой, такие как применение групповых и доменных политик безопасности, правил формирования и смены паролей, блокировка учетных записей, применение защищенных протоколов аутентификации с помощью шифрования паролей (Kerberos или NTLM).
Аутентификация с помощью SQL Server предназначена главным образом для клиентских приложений, функционирующих на платформах, отличных от Windows. Этот способ считается менее безопасным, но в SQL Server 2005 он поддерживает шифрование всех сообщений, которыми обмениваются клиент и сервер, в том числе с помощью сертификатов, сгенерированных сервером. Шифрование также повышает надежность этого способа аутентификации. Для учетной записи SQL Server можно указать такой параметр, как необходимость сменить пароль при первом соединении с сервером. Если SQL Server 2005 работает под управлением Windows Server 2003, можно воспользоваться такими параметрами учетной записи, как проверка срока действия пароля и локальная парольная политика Windows
·разделение прав с помощью схем:
принцип распределения прав доступа к объектам баз данных основан на наличии у каждого объекта базы данных пользователя-владельца, который может предоставлять другим пользователям права доступа к объектам базы данных. При этом набор объектов, принадлежащих одному и тому же пользователю, называется схемой.
В SQL Server 2005 концепция ролей расширена: эта СУБД позволяет полностью отделить пользователя от схем и объектов базы данных. Теперь объекты базы данных принадлежат не пользователю, а схеме, не имеющей никакого отношения ни к каким учетным записям и тем более к административным привилегиям. Таким образом, схема становится механизмом группировки объектов, упрощающим предоставление пользователям прав на доступ к объектам.
·механизм ролей:
Для упрощения управления правами доступа применяется механизм ролей — наборов прав доступа к объектам базы данных, присваиваемых некоторой совокупности пользователей. При использовании ролей управление распределением прав доступа к объектам между пользователями, выполняющими одинаковые функции и применяющими одни и те же приложения, существенно упрощается: создание роли и однократное назначение ей соответствующих прав осуществляется намного быстрее, нежели определение прав доступа каждого пользователя к каждому объекту. SQL Server 2005 позволяет создавать так называемые вложенные роли, то есть присваивать одной роли другую со всеми ее правами. Это упрощает управление не только правами пользователей, но и самими ролями, создавая, к примеру, сходные между собой группы ролей.
SQL Server 2005 также поддерживает так называемые роли для приложений (application roles), которые могут использоваться для ограничения доступа к объектам базы данных в тех случаях, когда пользователи обращаются к данным с помощью конкретных приложений. В отличие от обычных ролей, роли для приложений, как правило, неактивны и не могут быть присвоены пользователям. Их применение оказывается удобным в том случае, когда требования безопасности едины для всех пользователей, при этом не требуется аудит или иная регистрация деятельности конкретных пользователей в базе данных.
Выводы
В третьей главе курсовой работы проведен анализ и выбрана СУБД MicrosoftSQLServer 2005, в которой осуществлено физическое проектирование базы данных.
При этом построена схема базы данных, введены ограничения на информацию, составлены процедуры и триггеры, и получены отчеты. Для реализации форм и отчетов написаны программы на языке C# с использованием технологии доступа к базе данных LINQ.
В конце главы рассмотрены вопросы безопасности и контроля доступа к информации, хранящейся в базе данных.
Таким образом, разработанная автоматическая система управления полностью готова к опытной эксплуатации в учебном заведении «Компьютерные курсы».
Заключение
Разработанная автоматическая система управления «Компьютерные курсы» является актуальной в связи с высокой потребностью в автоматизации практически в любой сфере.
В курсовой работе решены следующие задачи:
В итоге разработана реляционная база данных, содержащая элементы автоматизации и обработки данных. База данных содержит следующие объекты:
Список источников и литературы: