Проектирование и реализация информационной системы "Кредитование"
Основные свойства и функции файл-сервера, клиент-сервера и двухуровневых моделей. Физические и проекционные составляющие данной информационной системы. Схема реляционной базы данных. Описание и содержание таблиц. Формы и запросы для обработки данных.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 02.12.2014 |
Размер файла | 1,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru
Размещено на http://www.allbest.ru
Аннотация
В данной курсовой работе рассматривается информационная система «Кредитование».
Структура данного курсовой работы выглядит следующим образом.
Первый раздел отражает основные свойства и функции файл-сервера, клиент-сервера и двухуровневых моделей.
Во втором разделе рассмотрены физические и проекционные составляющие данной информационной системы.
В третьем разделе была построена наглядная SADT-диаграмма, показывающая нам суть курсовой работы.
Введение
Сбор информации и изучение клиента. Клиент предоставляет следующие документы:
- заявление на предоставление кредита;
- документы, подтверждающие правоспособность заемщика;
- справки из ГНИ, пенсен. страх.;
- финансовые документы.
По итогам изучения клиента определяется категория риска клиента, риск сделки, рисковая цена кредитного продукта.
Если по итогам предварительной оценки клиента кредитный инспектор решает продолжить работу с кредитной заявкой, то документы направляются в Спецуправление и Отдел Залогов (ОЗ).
Спецуправление делает заключение о выдаче кредита или отказе, на основе анализа всех доступных данных о клиенте, которые могут влиять на кредитоспособность.
ОЗ проводит оценку предлагаемого в залог имущества и подготавливает свое заключение.
На основе заключения поддерживающих служб и заключения кредитного инспектора выносится Заключение о предоставлении кредита.
Клиенту направляется письмо с указанием основных условий кредита.
После подписания договора кредитный инспектор направляет в бухгалтерию банка следующие документы:
- копии кредитного договора, договора поручительства, залога;
- распоряжение на открытие ссудного счета;
- копии заявления заемщика.
После открытия ссудного счета в ГНИ направляется извещение об открытии счета.
1. Удаленные базы данных
1.1 Архитектура “Файл - Сервер”
Самой простой архитектурой для реализации является архитектура "файл-сервер" (рисунок 1), но она же обладает и самым большим количеством недостатков, ограничивающих спектр решаемых ею задач. Простейшим случаем является случай, когда данные располагаются физически на том же компьютере, что и само приложение.
Рисунок 1 - Структура информационной системы с файл сервером
К существенным неудобствам, возникающим при работе с системой, построенной по такой архитектуре, можно отнести следующее:
- трудности при обеспечении непротиворечивости и целостности данных;
- существенная загрузка локальной сети передаваемыми данными;
- в целом, невысокая скорость обработки и представления информации;
- высокие требования к ресурсам компьютеров. При этом возникают следующие ограничения.
- невозможность организации равноправного одновременного доступа; пользователей к одному и тому же участку базы данных;
- количество одновременно работающих с системой пользователей не превышает пяти человек для ЛВС, построенной в соответствии со спецификацией 10BaseT (скорость обмена данными до 10Мб/с);
При всем этом система обладает одним очень важным преимуществом - низкой стоимостью.
Архитектура "файл-сервер" предусматривает концентрацию обработки на рабочих станциях. Основным преимуществом этого варианта является простота и относительная дешевизна. Подобное решение приемлемо, пока число пользователей, одновременно работающих с базой данных, не превышает 5-10 человек. При увеличении количества пользователей система может "захлебнуться" из-за перегруженности ЛВС большими потоками необработанной информации.
Сервер, как правило, -- самый мощный и самый надежный компьютер. Он обязательно подключается через источник бесперебойного питания, в нем предусматриваются системы двойного или даже тройного дублирования. В особо ответственных случаях можно подключить вместе несколько серверов так, что при выходе из строя одного из них в работу автоматически включится "дублер". Таким образом, при концентрации обработки данных на сервере надежность системы в целом ограничивается только материальными средствами, которые заказчики готовы вложить в техническое оснащение.
Решение по автоматизации учета и управления в корпоративных структурах предполагает распределенную обработку данных, организацию параллельных вычислений, глубокое разграничение уровней доступа, возможность выбора различных операционных систем и серверных платформ. Если бизнес не велик, подобное решение оптимально.
В ходе эксплуатации были выявлены общие недостатки файл-серверного подхода при обеспечении многопользовательского доступа к базе данных.
Вся тяжесть вычислительной нагрузки при доступе к базе данных ложится на приложение клиента, что является следствием принципа обработки информации в системах "файл-сервер": при выдаче запроса на выборку информации из таблицы вся таблица базы данных копируется на клиентское место, и выборка осуществляется на клиентском месте. Локальные СУБД используют так называемый "навигационный подход", ориентированный на работу с отдельными записями.
Не оптимально расходуются ресурсы клиентского компьютера и сети; например, если в результате запроса мы должны получить 2 записи из таблицы объемом 10000 записей, все 10000 записей будут скопированы с файл-сервера на клиентский компьютер; в результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера.
В базе данных на файл-сервере гораздо проще вносить изменения в отдельные таблицы, минуя приложения. Эта возможность облегчается тем обстоятельством, что у локальных СУБД база данных -- понятие более логическое, чем физическое, поскольку под базой данных понимается набор отдельных таблиц, сосуществующих в едином каталоге на диске. Все это позволяет говорить о низком уровне безопасности - как с точки зрения хищения и нанесения вреда, так и с точки зрения внесения ошибочных изменений.
Недостаточно развитый аппарат транзакций для локальных СУБД служит потенциальным источником ошибок как с точки зрения одновременного внесения изменений в одну и ту же запись, так и с точки зрения отката результатов серий объединенных по смыслу в единое целое операций над базой, когда некоторые из них завершились неуспешно, а некоторые - нет; это может нарушать ссылочную и смысловую целостность базы данных.
Недостатки настольных СУБД обычно проявляются не сразу, а лишь в процессе длительной эксплуатации, когда объем хранимых данных и число пользователей становятся достаточно велики - это приводит к снижению производительности приложений, использующих такие СУБД.
Поскольку настольные СУБД не содержат специальных приложений и сервисов, управляющих данными, а используются для этой цели файловые сервисы операционной системы, вся реальная обработка данных в таких СУБД осуществляется в клиентском приложении, и любые библиотеки доступа к данным в этом случае также находятся в адресном пространстве клиентского приложения. Поэтому при выполнении запросов данные, на основании которых выполняется такой запрос, должны быть доставлены в то же самое адресное пространство клиентского приложения. Это и приводит к перегрузке сети при увеличении числа пользователей и объема данных, а также грозит иными неприятными последствиями, например разрушением индексов и таблиц. Недаром до сих пор популярны утилиты для "ремонта" испорченных файлов настольных СУБД.
Недостатки архитектуры "файл-сервер" решаются при переводе приложений в архитектуру "клиент-сервер", которая знаменует собой следующий этап в развитии СУБД. Характерной особенностью архитектуры "клиент-сервер" является перенос вычислительной нагрузки на сервер базы данных (SQL-сервер) и максимальная разгрузка приложения клиента от вычислительной работы, а также существенное укрепление безопасности данных - как от злонамеренных, так и просто ошибочных изменений.
БД в этом случае помещается на сетевом сервере, как и в архитектуре "файл-сервер", однако прямого доступа к базе данных (БД) из приложений не происходит. Функция прямого обращения к БД осуществляет специальная управляющая программа - сервер БД (SQL-сервер), поставляемый разработчиком СУБД.
1.2 Архитектура “Клиент - Сервер”
Модель "клиент-сервер" связана с принципом открытых систем. Термин "клиент-сервер" исходно применялся в архитектуре ПО, которое ориентировало распределение процесса выполнения по принципу взаимодействия 2-х программ, процессов, один из которых в этой модели назывался клиентом, а другой - сервером. При этом предполагалось, что один серверный процесс может обслуживать множество клиентских процессов.
Ранее приложение (пользовательская программа) не разделялось на части, а выполнялось монолитным блоком, но при рациональном использовании ресурсов сети данный принцип не актуален. Теперь все ПК в сети обладают собственными ресурсами и разумно так распределить нагрузку на них, чтобы максимальным образом использовать их ресурсы. Основной принцип технологии "клиент-сервер" в БД заключается в разделении функций стандартного интерактивного приложения на 5 групп:
Функция ввода и отображения данных (PL);
Прикладные функции, определяющие основные алгоритмы решения задач приложения (BL);
Функции обработки данных внутри приложения (DL);
Функции управления информационными ресурсами (DML);
Служебные функции, играющие роль связок между функциями 1-х и 4-х групп.
Рисунок 2 - Приложение работающее с БД
PL - это часть приложения, которая определяется тем, что пользователь видит на экране, когда работает приложение (интерактивные экранные формы, а также все то, что выводится пользователю на экран, результаты решения некоторых промежуточных задач, справочная информация).
Основные задачи PL:
формирование экранных изображений;
чтение и запись в экранные формы информации;
управление экраном;
обработка движений мыши и нажатий клавиш клавиатуры.
BL - это часть кода приложения, которая определяет алгоритмы решения конкретных задач приложения. Обычно этот код пишется с использованием различных языков программирования.
DL - это часть кода приложения, которая связана с обработкой данных внутри приложения (данными управляет собственно СУБД), где используется язык запросов и средства манипулирования данными стандартного языка SQL. Процессор управления данными (Data Base Manager System Processing) - это собственно СУБД, которая обеспечивает управление и хранение данных. В идеале СУБД должна быть скрыта от BL-приложения. Однако для рассмотрения архитектуры приложения нам надо их выделить в отдельную часть приложения.
1.3 Двухуровневые модели
Эти модели фактически являются распределением пяти указанных функций между двумя процессами, которые выполняются на двух платформах - клиенте и сервере.
Модель удаленного управления данными (модель файлового сервера). В этой модели BL и PL располагаются на клиенте. На сервере располагаются файлы с данными и доступ к ним. Функции управления информационными ресурсами в этой модели находятся на клиенте.
Рисунок 3 - Модель “Файл-Сервер”
В этой модели файлы БД хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм управления всеми информационными ресурсами (база метаданных (БМД)) находится на клиенте.
Достоинства:
разделение монопольного приложения на два взаимодействующих процесса.
сервер может обслуживать множество клиентов, которые обращаются к нему с запросами.
Алгоритм выполнения запроса клиента.
Запрос клиента формируется в командах ЯМД. СУБД переводит этот запрос в последовательность файловых команд. Каждая файловая команда вызывает перекачку блока информации на клиента. Далее на клиенте СУБД анализирует полученную информацию и если в полученном блоке не содержится ответ на запрос, то принимается решение о перекачке следующего блока информации до тех пор, пока не будет найдено ответа на запрос.
Модель удаленного доступа к данным.
В модели удаленного доступа (RDA) база данных хранится на сервере. На нем же находится и ядро СУБД. На клиенте располагаются PL и BL приложения. Клиент обращается к серверу с запросами на языке SQL.
Рисунок 4 - Модель RDA
Достоинства:
перенос компонента представления и прикладного компонента на клиентский ПК существенно разгружает сервер БД, сводя к минимуму общее число процессов в ОС.
процессор сервера целиком загружается операциями обработки данных, запросов и транзакций.
резко уменьшается загрузка сети, запросы на ввод-вывод и на SQL уменьшаются в объеме, т.е. в ответ на запросы клиент получает только данные, удовлетворяющие данному запросу.
унификация интерфейса клиент-сервер.
стандартным при обращении приложения клиента и сервера становится язык SQL.
Недостатки:
запросы на SQL при интерактивной работе клиента могут существенно загрузить сеть.
на клиенте располагаются PL и BL, и если при повторении аналогичных функций в различных приложениях (других клиентов) их код должен быть повторен для каждого клиентского приложения, следовательно, дублирование кода приложения.
сервер в этой модели играет пассивную роль, поэтому функции управления информационными ресурсами должны выполняться на клиенте => это усложняет клиентское приложение.
Модель сервера баз данных.
Для того, чтобы избавиться от недостатков модели удаленного доступа должны быть соблюдены следующие условия:
Данные, которые хранятся в БД в каждый момент времени должны быть непротиворечивы.
БД должна отображать некоторые правила ПО, законы ПО.
Необходим постоянный контроль за состоянием БД, отслеживание всех изменений и адекватная реакция на них.
Возникновение некоторой ситуации в БД четко и оперативно должно влиять на ход выполнения прикладной задачи.
Одной из важных проблем СУБД является контроль типов данных через язык описания данных (ЯОД).
Рисунок 5 - Модель активного сервера
Данную модель поддерживают большинство современных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server.
Основу данной модели составляет механизм хранимых процедур (как средства программирования SQL-сервера), механизм триггеров (как механизм отслеживания текущего состояния информационного хранилища) и механизм ограничений на пользовательские типы данных (который иногда называется механизмом поддержки доменной структуры).
В этой модели бизнес логика разделена между клиентом и сервером. На сервере бизнес логика реализована в виде хранимых процедур - специальных программных модулей, которые хранятся в БД и управляются непосредственно СУБД. Клиентское приложение обращается к серверу с командой запуска хранимой процедурой, а сервер выполняет эту процедуру и регистрирует все изменения в БД, которые в ней предусмотрены. Сервер возвращает клиенту данные, релевантные его запросу. Централизованный контроль в данной модели выполняется с использованием механизма триггеров, которые являются частью БД.
Триггер - механизм отслеживания специальных событий, которые связаны с состоянием БД. Триггер в БД является как бы некоторым тумблером, который срабатывает при возникновении определенного события в БД. Ядро СУБД проводит мониторинг всех событий, которые вызывают созданные и описанные триггеры в БД, и при возникновении соответствующего события сервер запускает соответствующий триггер => триггер - это программа, которая выполняется над БД и вызывает хранимые процедуры.
Данная модель сервера является активной, потому что не только клиент, но и сам сервер используют механизм триггеров.
Достоинства:
- Хранимые процедуры и триггеры хранятся в словаре БД и могут быть использованы несколькими клиентами => уменьшается дублирование алгоритмов обработки данных в разных клиентских приложениях.
Недостатки:
- Очень большая загрузка сервера.
Функции сервера:
Осуществляет мониторинг событий, связанных с описанными триггерами;
Обеспечивает автоматическое срабатывание триггеров при возникновении связанных с ними событий;
Обеспечивает исполнение внутренней программы каждого триггера;
Запускает хранимые процедуры по запросам пользователей;
Запускает хранимые процедуры из триггеров;
Возвращает требуемые данные клиенту;
Обеспечивает все функции СУБД: доступ к данным, контроль и поддержка целостности данных в БД, контроль доступа, обеспечение корректной работы всех пользователей с единой БД.
2. Проектирование базы данных
2.1 Описание предметной области
В данной курсовой работе рассматривается Кредитование. Данная информационная система обеспечивает: сбор информации и изучение клиента, состав финансовых документов, данные о клиентах, категории риска и т.д. Информационная система реализует запросы упорядочения по полям: Сумма от имущества под залог, сумма кредита.
Главными требованиями, положенными в основу при разработке комплекса стали: лёгкое использование и расширяемость. Поэтому комплекс разбивается на несколько основных программных блоков (модулей):
- Категории риска;
- Клиенты;
- Финансовые документы.
2.2 Схема реляционной базы данных
Совокупность реляционных таблиц, логически взаимосвязанных и отражающих некоторую предметную область, образует реляционную базу данных. Группа связанных таблиц называется схемой данных.
В результате моделирования получена реляционная модель следующего вида:
1). Категории риска (Категория риска, Рисковая цена, Риск сделки);
2). Клиенты (Код клиента, Фамилия, Имя, Отчество, Место жительства, Место работы, Контактный телефон, Категория заемщика, Сумма кредита);
3). Финансовые документы (Код клиента, Паспорт, Свидетельство о внесении в ЕГР, Заявление на получение кредита, Справки из ГНИ, Сумма от имущества под залог);
Рисунок 6 - Схема реляционной базы данных «Кредитование»
2.3 Физическая модель базы данных
Физическая модель базы данных выполняется на основе логической.
Описание физической структуры реляционных таблиц приведено в таблицах 9 - 11
Получить информацию обо всех типов данных таблицы «Категории риска» можно на рис. 7
Рисунок 7 - Таблица «Категории риска»
Получить информацию обо всех типов данных таблицы «Клиенты» можно на рис. 8
Рисунок 8 - типы данных таблицы «Клиенты»
Получить информацию обо всех типов данных таблицы «Финансовые документы» можно на рис. 9
Рисунок 9 - типы данных таблицы «Финансовые документы»
2.4 Описание и содержание таблиц
Для создания базы данных, после запуска программы Microsoft Access выбираем во вкладке «Файл» пункт «Создать», затем выбираем «Новая база данных». На экране появляется окно выбора объектов для создания. В появившемся окне открываем вкладку «Таблицы». Выбираем пункт «Создание таблицы в режиме конструктора».
Составляем список строк и столбцов, необходимых в нашей таблице. В ходе создания мы можем сразу дать название таблице, колонкам, указать тип данных, которые будут заноситься в эти столбцы.
Для реализации данной базы данных требуется четыре таблицы.
Таблица для хранения данных о категориях риска представлена на рисунке 10
Рисунок 10 - Таблица «Категории риска»
Таблица для хранения данных о финансовых документах
Рисунок 11 - Таблица «Финансовые документы»
Таблица для учёта клиентов представлена на рисунке
Рисунок 12 - Таблица «Клиенты»
2.5 Формы для обработки данных
Формы позволяют создавать пользовательский интерфейс для таблиц базы данных. Хотя для выполнения тех же самых функций можно использовать режим таблицы, формы предоставляют преимущества для представления данных в упорядоченном и привлекательном виде. Формы позволяют также создавать списки значений для полей, в которых для представления множества допустимых значений используют коды. Правильно разработанная форма ускоряет процесс ввода данных и минимизирует ошибки.
Формы создают из набора отдельных элементов управления: текстовые поля для ввода и редактирования данных, кнопки, флажки, переключатели, списки, метки полей, а также рамки объектов для отображения графики и объектов OLE. Форма состоит из окна, в котором размещаются два типа элементов управления: динамические (отображающие данные из таблиц) и статистические (отображающие статистические данные, такие как метки и логотипы).
Простейший путь создания основной и подчинённой форм - использование «Мастера форм», который позволяет создавать формы, содержащие поля из одной или более таблиц или запросов. «Мастер форм» создает базовый внешний вид формы и добавляет текстовые поля для отображения и редактирования значений полей таблиц. «Мастер форм» заметно упрощает и ускоряет процесс создания простых форм, которые затем можно усовершенствовать в режиме конструктора.
Форма состоит из трёх частей: заголовок формы, область данных и примечание формы. В заголовке формы указывается название формы. В области данных располагаются всевозможные объекты: поля, кнопки и т.д. В примечании формы обычно располагаются вспомогательные объекты, такие, как подчинённая форма и т.д.
В данной базе данных присутствует три необходимые для работы формы. Одна из них является главной формой. Две остальные формы являются вспомогательными и используются по ссылке из главной формы.
Ниже приведены основные формы, используемые в базе данных.
Главная форма кредитования отражена на рис. 13
Рисунок 13 - Главная форма «Кредитование»
В форме «Извещение о выдаче кредита» можно найти данные обо всех заемщиках, которым было дано разрешение о выдаче кредита, и все данные, необходимые банку для предоставления кредита (рис. 14)
Рисунок 14 - форма «Извещение о выдаче кредита»
Справка клиенту - в ней можно получить данные о документах, которые предоставил клиент для получения кредита, а также о сумме кредита и сумме от имущества под залог (рис. 15)
Рисунок 15 - форма «Справка клиенту»
2.6 Запросы
информационный кредитование база данные
Запросы служат для извлечения данных из таблиц и предоставления их пользователю в удобном виде. Особенность запросов состоит в том, что они черпают данные из базовых таблиц и создают на их основе временную таблицу. В виде таблицы появляется временный набор записей. Здесь отображаются также записи, добавляемые, удаляемые или изменяемые в исходных таблицах.
В данной базе данных содержится 2 запроса.
Запрос на обновление, который вычисляет коэффициент для каждого клиента, по которому определяется возможность предоставления кредита
Рисунок 16 - запрос «Коэффициент»
Запрос содержит одно поле для обновления - «Коэффициент». Оно находится в таблице клиенты, и рассчитывается по формуле (2.1):
, (2.1)
где Sum(K) - сумма кредита, которую необходимо получить клиенту;
Sum(Z) - сумма от имущество под залог, которую может предложить клиент.
Для получения кредита, X должен быть равен больше 1,2.
Структура запроса представлена на рис. 17
Рисунок 17 - структура запроса «БТИ»
Запрос, который осуществляет выборку по вычисленному коэффициенту
Рисунок 18 - запрос «Выборка»
Запрос содержит поля таблиц «Код клиента», «Коэффициент», «Справки из ГНИ», «Рисковая цена», «Сумма кредита».
При вызове запроса «Выборка» программа выберет записи по условию, что «Коэффициент»>1,2 , по справкам из ГНИ клиент «без задолженностей», и «Рисковая цена»>= «Сумма кредита».
Структура запроса представлена на рис. 19
Рисунок 19 - структура запроса «Выборка»
2.7 Описание комплекса программных и аппаратных средств
Описание аппаратных средств:
- Операционная система - Microsoft® Windows7.
- Описание программных средств:
- СУБД Microsoft Access 2007 - используемая для создания БД «Кредитование».
- Microsoft Office Word 2007 - текстовый редактор, используемый, для оформления.
Заключение
Данный курсовой проект разработан для создания информационной системы Кредитование. Создание базы данных обусловлено необходимостью сбора информации и изучении клиента. Определения категории: риска клиента, риска сделки, рисковой цены кредитного продукта.
В процессе разработки была использована реляционная модель, которая позволила спроектировать базу данных, в которой нет ненужных избыточных данных и противоречий, которые могли бы в дальнейшем привести к порче информации. Также была обеспечена целостность данных, которая способствовала непротиворечивости и адекватности отражаемых сведений.
Было осуществлено построение так называемой SADT-модели, необходимой для корректной организации отображения и просмотра БД.
Список использованных источников
1.Вендров, А.М. Проектирование программного обеспечения экономических информационных систем : учебник / А.М. Вендров. - М. : Финансы и статистика, 2006. - 352 с. - ISBN 5-279-02937-8
2.Вендров, А.М. Проектированию программного обеспечения экономических информационных систем : практикум / А.М. Вендров. - М. : Финансы и статистика, 2006. - 192 с. - ISBN 5-279-03106-2
3.Орлов, С.А. Технология разработки программного обеспечения : учебник. / С.А. Орлов. - СПб. : Питер, 2002. - 609 с. - ISBN: 978-5-459-01101-2
4.Канер, С. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений : учебник. / C. Канер, Дж. Фолк, Енг Кек Нгуен. - К. : «ДиаСофт», 2001. - 544 с. - ISBN: 966-7393-87-9
5.Хомоненко, А.Д. Базы данных : учебник. / А.Д. Хомоненко, В.М. Цыганков, М.Г. Мальцев. - СПб. : КОРОНА принт, 2002. - 672 с. - ISBN 5-7931-0168-3
6.Черемных, С.В. Моделирование и анализ систем. IDEF- технологии: практикум. / С.В. Черемных, И.О. Семенов, В.С. Ручкин. - М. : Финансы и статистика, 2006. - 192 с. - ISBN 5-279-02564-Х
Размещено на Allbest.ru
...Подобные документы
Определение базовых сущностей предметной области. Представление базы данных реляционной моделью. Построение ER-диаграмм. Функции и архитектура информационной системы. Создание таблиц БД на языке SQL Server. Запросы на выборку и манипулирование данными.
курсовая работа [1,8 M], добавлен 06.05.2015Системный анализ предметной области. Нормальные формы таблиц. Физическое проектирование базы данных. Реализация структуры БД в СУБД MySQL. Запросы на создание таблиц, добавление и выборку данных. Реализация триггера и функции. Программный код WEB-страниц.
курсовая работа [748,9 K], добавлен 01.11.2014Проектирование информационной системы. Построение диаграммы потоков данных. Описание порядка построения DFD-диаграммы. Создание базы данных с помощью SQL сервера. Описание основных бизнес-правил и их физической реализации. Заполнение таблиц данными.
курсовая работа [1,5 M], добавлен 13.12.2011Детализация функций системы и требования к информационной системе. Анализ категорий пользователей. Этапы внедрения автоматизированной информационной системы на предприятии. Описание таблиц базы данных. Защита данных от несанкционированного доступа.
дипломная работа [1,0 M], добавлен 22.07.2015Описание состава реляционной базы данных как системы связанной информации, сохраняемой в двумерных таблицах. Основные функции CMS и изучение структуры сервера MySQL. Разработка системы выборок данных по товарам для интернет-магазина, таблицы покупателей.
курсовая работа [2,0 M], добавлен 21.04.2015Проектирование автоматизированной информационной системы, позволяющей оформлять заказы на продажу керамической плитки. Разработка реляционной модели данных. Структура и содержание таблиц базы данных, формирование запросов к ней и назначение ее форм.
курсовая работа [4,9 M], добавлен 26.07.2013Варианты использования информационной системы: заказ билета, просмотр каталога фильмов и списка кинотеатров. Проектирование реляционной модели базы данных, ее мапирование в метамодель, логическая и физическая реализация. Результаты работы программы.
курсовая работа [673,9 K], добавлен 20.11.2011Рассмотрение архитектуры "файл-сервер" и двух- и трехуровневых архитектур "клиент-сервер". Модель сервера приложений и свойства "идеальной" системы управления распределенными базами данных. Способы распределения функций обработки логики запроса.
презентация [60,2 K], добавлен 19.08.2013Инфологическое проектирование базы данных. Создание информационной системы "СПОРТ" для автоматизации обработки данных о проводимых соревнованиях и чемпионатах. Описание размещения в файловой системе. Создание таблиц, запросов и форм просмотра данных.
курсовая работа [4,6 M], добавлен 22.05.2012Создание информационной системы товарооборота на основе использования технологий баз данных кирпичного завода. Физическая модель базы данных. Проектирование БД в СУБД Microsoft SQL Server. Схема функциональной структуры программной системы. Запросы к БД.
курсовая работа [3,5 M], добавлен 05.03.2015Реляционные базы данных как часть корпоративных информационных систем, их построение по принципам клиент-серверной технологии. Основные характеристики СУБД Firebird. Проектирование базы данных для информационной системы "Компьютерные комплектующие".
курсовая работа [1,9 M], добавлен 28.07.2013Назначение создания информационной системы "Электронный журнал" для автоматизации контроля учебного процесса. Построение логической и реляционной моделей данных. Разработка клиент-серверного приложения для работы с базой данных; программная реализация.
дипломная работа [5,9 M], добавлен 19.01.2017Задачи, функции и структура филиала университета. Оценка информационных потоков и UML-моделирование. Анализ структуры информационной системы и системы навигации. Проектирование базы данных, физическая реализация и тестирование информационной системы.
дипломная работа [6,0 M], добавлен 21.01.2012Методика и основные этапы разработки информационной системы туристического агентства, основные требования к ней. Внутренняя структура и элементы данной системы, принцип работы с ней и оценка функциональности. Описание таблиц разрабатываемой базы данных.
контрольная работа [881,5 K], добавлен 08.06.2014Архитектура "клиент-сервер". Системный анализ базы данных "Газета объявлений", ее инфологическое и физическое проектирование. Программирование на стороне SQL-сервера. Разработка клиентской части в Borland C++ Builder 6.0 и с помощью Web-технологий.
курсовая работа [1,3 M], добавлен 07.07.2013Общая характеристика и структура проектируемой базы данных, содержание основных таблиц и запросов, предъявляемые требования. Механизм построения информационной и реляционной модели. Описание данных и инициализация, реализация серверного приложения.
курсовая работа [586,3 K], добавлен 31.03.2015Описание особенностей функционирования магазина. Проектирование системы: инфологическое моделирование и построение диаграммы потоков данных. Моделирование и программная реализация информационной системы. Проектирование пользовательского интерфейса.
курсовая работа [1,6 M], добавлен 18.02.2013Выявление сущностей и связей, атрибутов сущностей и назначение первичных ключей при разработке базы данных. Реляционная модель данных. Описание стадий жизненного цикла информационной системы: анализ, проектирование, реализация, внедрение, сопровождение.
курсовая работа [152,2 K], добавлен 11.05.2014Проектирование информационной системы "телефонный справочник поликлиники". Программирование на стороне сервера SQL. Типы данных полей таблиц. Создание домена в интернет с использованием утилиты IBExpert. Разработка бизнес-логики на стороне SQL-сервера.
курсовая работа [2,7 M], добавлен 02.05.2014Разработка информационно-логической модели проектируемой информационной системы. Алгоритм функционирования информационной системы. Описание базы данных. Описание входной, промежуточной и выходной информации. Техническое и программное обеспечение.
реферат [28,1 K], добавлен 09.01.2009