методов защиты БД на основе Visual FoxPro для предметной области воздушные перевозки

  методов защиты БД на основе Visual FoxPro для  предметной области воздушные перевозки

Содержание
Задание........................................................................................................................ 2
Содержание................................................................................................................. 3
Введение...................................................................................................................... 4
1 Разработка информационной модели проектирования базы данных................ 6
1.1 Инфологическая модель предметной области........................................ 6
1.2 Даталогическая модель предметной области.......................................... 8
2 Разработка прикладной программы....................................................................... 10
2.1 Разработка функциональной структуры приложения............................ 10
2.2 Разработка защиты базы данных.............................................................. 11
2.3 Разработка приложения базы данных...................................................... 13
3 Инструкции.............................................................................................................. 19
3.1 Инструкция для пользователя................................................................... 19
3.2 Инструкция для сопровождающего программиста................................ 28
Заключение................................................................................................................. 30
Список литературы.................................................................................................... 31
Приложение А............................................................................................................ 32
Приложение Б............................................................................................................. 91

ВВЕДЕНИЕ
Базой данных (БД) называют специальным образом организованные данные, хранимые в вычислительной системе (ВС). БД создается для определенной предметной области (банк, библиотека, магазин, биржа и т.д.). Сегодня БД можно встретить практически везде. Их используют в медицине, на транспорте, в правоохранительных органах, в городских справочных службах, на производстве и в учебных заведениях. БД могут содержать в себе различную информацию, получить которую можно в считанные секунды, нажав для этого всего лишь несколько клавиш на клавиатуре компьютера.
Для создания и использования БД служат системы управления базами данных (СУБД), которые занимают особое место в мире программного обеспечения и нашей повседневной жизни. СУБД обеспечивают реализацию новых концепций в организации информационных служб через создание информационных систем на основе технологии БД. В настоящее время широко применяются муниципальные, банковские, биржевые информационные системы, информационные системы оптовой и розничной торговли, торговых домов, служб управления трудом и занятостью, справочной и аналитико–прогнозной котировочной информации и др. как правило, работа этих систем осуществляется в локальных вычислительных сетях различной архитектуры или их объединениях, получивших название корпоративных сетей, дальнейшая интеграция которых возможна с помощью глобальной сети Интернет.
Подавляющее большинство современных СБД представляют собой системы реляционного типа, т.е. использующие реляционную модель данных. Данные в реляционных БД хранятся в таблицах – отношениях (relation). Реляционные СБД (РСБД) – это компьютеризованные системы хранения записей в табличном виде. Под БД в различных РСБД понимается табличное хранение данных, но название «база данных» может объединять не только таблицы, но и производные этих таблиц ( в виде отчетов, форм, виртуальных таблиц – представлений), формы запросов, программные модули и т.д. СУБД, поддерживающие реляционную модель данных, называются реляционными СУБД (РСУБД). Стандартным языком взаимодействия с реляционными БД является язык запросов SQL, который реализуется в РСУБД на основе операций реляционной алгебры и реляционного исчисления.
Основной целью курсовой работы является приобретение практических навыков по разработке баз данных, программной реализации приложений БД и методов защиты БД для определенной предметной области на основе конкретной СУБД.
В курсовой работе должна быть разработана база данных и реализовано приложение БД с использованием методов защиты БД в среде конкретной СУБД для определенной предметной области (ПО). Для выполнения этой задачи необходимо выполнить: анализ ПО; определить функции, подлежащие реализации в системе; выделить параметры ПО, необходимые для выполнения индивидуального задания; выбрать метод защиты БД. На основе проведенного анализа осуществляется постановка задачи, разработка информационной и даталогической моделей ПО, алгоритмов решения задачи, их реализация.
Курсовая работа состоит из трех разделов: разработки информационной модели и проектирования базы данных; разработки приложения БД с использованием методов и средств защиты; разработки инструкций для работы с БД.
1 РАЗРАБОТКА ИНФОРМАЦИОННОЙ МОДЕЛИ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ
1.1 Инфологическая модель предметной области
Инфологическая модель – это описание предметной области без ориентации на используемые аппаратные и программные средства.
Цель инфологического моделирования – обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных строят по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются объекты, связи между ними и их атрибуты. Атрибуты – это существенные свойства объекта, интересующие пользователя.
Выполняя анализ предметной области воздушные перевозки, определяем объекты, которые должны интересовать конечного пользователя. Можно выделить два объекта:
Объект1 – Расписание рейсов.
Объект2 – Пассажиры.
Рассмотрим связь между данными объектами (рисунок 1). Один пассажир может лететь только одним рейсом, что на рисунке показано одной стрелкой, в то время как, на одном и том же рейсе могут лететь много пассажиров, что на рисунке показано двойной стрелкой. Следовательно между данными объектами реализуется отношение 1: М. Связь между таблицами осуществляется по полю: Номер рейса.
Рисунок 1 - Тип связей между объектами Врачи и Пациенты.
Реляционная модель, не содержит связей типа многие-ко-многим, необходимо ввести промежуточное отношение для промежуточного объекта, которое будет содержать идентификаторы связываемых объектов. В нашем случае таким новым объектом для связи служит объект Прием, идентификаторами которого являются код врача, номер карты пациента, дата приема и т. д. Каждый пациент может прийти на прием к нескольким врачам, поэтому связь между объектами Пациенты и Прием будет один-ко-многим (см. рис. 2). Каждый врач принимает множество пациентов, поэтому связь между объектами Врачи и Прием также будет один-ко-многим (см. рис. 2).
Рисунок 2 - Типы связей между объектами Врачи, Пациенты и Прием.
В реляционной базе данных в качестве объектов рассматриваются отношения, которые можно представить в виде таблиц. Таблицы между собой связываются посредством общих полей, т.е. одинаковых по форматам и, как правило, по названию, имеющихся в обеих таблицах. Рассмотрим, какие общие поля надо ввести в таблицы для обеспечения связности данных. В таблицах Врачи и Прием таким полем будет «Код врача», в таблицах Пациенты и Прием - «Номер карты».
В соответствии с этим информационная структура объектов представлена в таблице 1.
Таблица 1 – Информационная структура объектов
Объект Атрибуты Значения
Врачи код врача 1
фамилия, имя, отчество Казакова Любовь Ярославовна
специалист кардиолог
адрес 10 микрорайон, дом 5, кв. 81
домашний телефон 382201
Пациенты номер карты 1001
фамилия, имя, отчество Петров Виталий Олегович
домашний телефон 210375
пол мужской
дата рождения 08.12.1969
адрес Дежнева, 26, кв. 7
прикрепленный житель нет
№ страхового полиса 11203
вид страхования добровольное
взят на диспансерное наблюдение да
Продолжение таблицы 1
Прием номер карты 1001
код врача 1
повод обращения диспансеризация
кем направлен скорой помощью
дата приема 01.13.2004
Первичный ключ – это атрибут (совокупность атрибутов), однозначно идентифицирующий конкретную запись. Таким ключем для объекта Врачи является атрибут «Код врача», для объекта Пациенты – «Номер карты», а для объекта Прием - совокупность атрибутов «Код врача»+ «Номер карты»+«Дата приема».
Внешний ключ – это атрибут (совокупность атрибутов), не являющихся первичным ключом для данного объекта, но который является первичным ключом для логически связанного объекта. Таким ключем для объекта Прием является атрибут «Код врача», а так же «Номер карты».
1.2 Даталогическая модель предметной области
Даталогическая модель представляет собой отображение логических связей между элементами данных безотносительно к их содержанию и среде хранения. При этом даталогическая модель разрабатывается с учетом конкретной реализации СУБД и с учетом специфики конкретной предметной области на основе ее инфологической модели.
В реляционной базе данных все данные хранятся в виде таблиц, при этом все операции над базой данных сводятся к манипуляции с таблицами. В таблице 2 показана структура таблиц для предметной области поликлиника.

Таблица 2 – Структура таблиц мед_карта, врачи и прием1
Таблица Название поля Описание Тип поля Длина поля
мед_карта номеркарты номер карты Numeric 10
фио фамилия, имя, отчество Character 40
домтелефон домашний телефон Numeric 6
пол пол Character 1
дата_рожд дата рождения Date 8
адрес адрес Character 40
Продолжение таблицы 2
мед_карта прикреп_ж прикрепленный житель Logical 1
номерполис № страхового полиса Numeric 10
видстрахов вид страхования Character 12
диспансер взят на диспансерное наблюдение Logical 1
врачи код_врача код врача Numeric 6
фио фамилия, имя, отчество Character 40
наим_проф специалист Character 20
адрес адрес Character 30
телефон домашний телефон Numeric 6
прием1 номеркарты номер карты Numeric 10
код_врача код врача Numeric 6
поводобращ повод обращения Character 20
кемнаправл кем направлен Character 20
датаприема дата приема Date 8
Таблицы состоят из строк и столбцов и имеют уникальные имена в базе данных. База данных содержит множество таблиц, связь между которыми устанавливается с помощью совпадающих полей. В каждой из таблиц содержится информация о каких-либо объектах одного типа.
2 РАЗРАБОТКА ПРИКЛАДНОЙ ПРОГРАММЫ
2.1 Разработка функциональной структуры приложения
В этом разделе подробно описывается функциональные возможности создаваемой базы данных, в частности, основные блоки создаваемого приложения базы данных (см. рис. 3).
Определим функциональные задачи, решаемые нашим приложением.
В каждой поликлинике имеется регистратура. Она содержит картотеку на каждого пациента данной поликлиники (медицинская карточка больного), и данные о сотрудниках поликлиники. Следовательно пользователь должен иметь возможность изменять данные пациента или врача (например, человек сменил место жительства, поменял фамилию и т. д.), удалять данные о пациенте (например, пациент перешел в другую поликлинику) или о враче (сотрудник уволился), добавлять данные (например, в данной поликлинике зарегистрировался новый пациент или на работу приняли нового сотрудника) и осуществлять поиск данных о пациенте или враче. Так же в поликлинике ведутся записи о каждом приеме, поэтому пользователь должен иметь возможности ввода, удаления и редактирования данных о приеме.
Для решения вышеперечисленных задач используются формы, являющиеся основой пользовательского интерфейса..
Для корректной работы нужно определить тип механизма поддержки ссылочной целостности. Ссылочное ограничение целостноти – это поддержка непротиворечивости данных в связанных между собой таблицах, например, код врача в таблице врачи должен соответствовать коду врача в таблице прием1. Поэтому на удаление ставится Restrict (недопускает удаление строк с первичным ключом, если в дочерней таблице есть зависимые записи, связанные через внешний ключ), а на изменение – Cascade (при изменении первичного .....


Толық нұсқасын 30 секундтан кейін жүктей аласыз!!!


Әлеуметтік желілерде бөлісіңіз:
Facebook | VK | WhatsApp | Telegram | Twitter

Қарап көріңіз 👇



Пайдалы сілтемелер:
» Туған күнге 99 тілектер жинағы: өз сөзімен, қысқаша, қарапайым туған күнге тілек
» Абай Құнанбаев барлық өлеңдер жинағын жүктеу, оқу
» Дастархан батасы: дастарханға бата беру, ас қайыру

Соңғы жаңалықтар:
» Су тасқынынан зардап шеккендерге қосымша тағы 553 мың теңге төленеді
» Елімізде TikTok желісі бұғатталуы мүмкін бе?
» Елімізде су тасқынынан зардап шеккендердің қандай мүліктеріне өтемақы төленеді?