Главная страница
Навигация по странице:

  • Проблема исследования

  • Предмет исследования

  • 1 Аналитическая часть 1.1 Описание предметной области

  • 1.2 Структурный анализ бизнес-процессов

  • 1.3 Требования к проектируемой БД

  • 2 Проектная часть 2.1 Концептуальное проектирование

  • 2.2 Логическое проектирование

  • 2.3 Физическое проектирование

  • Список использованных источников Литература

  • Контекстная диаграмма IDEF 0 «Работа классного руководителя»

  • ER–диаграмма предметной области «Классный руководитель»

  • Логическая модель БД АРМ классного руководителя

  • КУРСОВАЯ РАБОТА ПРОЕКТИРОВАНИЕ АРМ КЛАССНОГО РУКОВОДИТЕЛЯ. Курсовая 2.06.21. Актуальность исследования


    Скачать 313.54 Kb.
    НазваниеАктуальность исследования
    АнкорКУРСОВАЯ РАБОТА ПРОЕКТИРОВАНИЕ АРМ КЛАССНОГО РУКОВОДИТЕЛЯ
    Дата28.11.2021
    Размер313.54 Kb.
    Формат файлаdocx
    Имя файлаКурсовая 2.06.21.docx
    ТипОтчет
    #284175

    Введение

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

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

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

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

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

    Данная курсовая работа посвящена проектированию АРМ классного руководителя.

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

    Все вышесказанное и определило аппарат исследования.

    Проблема исследования: каковы возможности автоматизации деятельности классного руководителя.

    Объект исследования: процессы, подлежащие автоматизации деятельности классного руководителя.

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

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

    Для достижения поставленной цели необходимо решить следующие задачи:

    1) исследовать предметную область и выявить состав пользователей и задач по обработке информации, которые нужно автоматизировать;

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

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

    1 Аналитическая часть

    1.1 Описание предметной области


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

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

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

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

    Удалением информации и пополнением базы будет заниматься так же, преподаватель. О каждом ученике будет храниться только необходимая информация: ФИО, дата рождения, номер телефона, номер в журнале, так же можно посмотреть данные о предмете. Информация обычно изменяется со средней периодичностью раз в 3–6 месяца.

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

    Текущая деятельность учителя – это регистрация новой оценки и факта посещения учеником учебного заведения. После регистрации в учебном заведении в базу записываются все данные ученика, а именно: номер телефона, номер в журнале, ФИО, дата рождения. Данные о оценках и посещаемости используются для еженедельных и ежемесячных отчетов. При использовании БД можно копировать устаревшие записи в архив, а из текущей БД устаревшие записи журнала удалять по мере необходимости. Данные архива в дальнейшем можно использовать для сбора статистики и ее анализа [13].

    Таким образом, мы выполнили описание разрабатываемой АРМ, определились со структурой предприятия и задачами, которые будет решать ИС.

    1.2 Структурный анализ бизнес-процессов


    Рассмотрим подробнее работу МБОУ «Октябрьская общеобразовательная школа». Во время проведения обследования общеобразовательного учреждения были выявлены:

    1. целевые задачи;

    2. функциональные деятельности каждого из подразделений СОШ и функциональные взаимодействия между ними;

    3. информационные потоки внутри подразделений и между ними;

    4. внешние по отношению к ООШ объекты и внешние информационные воздействия;

    5. нормативно-справочная документация, данные по имеющимся в школе средствам и системам автоматизации [13].

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

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

    Для контекстного процесса ООШ определим необходимую информацию:

    1. входная информация – опыт, информация;

    2. управление – директор, положение о работе классного руководителя;

    3. механизмы – ученики, ПК, родители;

    4. выходная информация – план классного руководства.

    Модель бизнес-процессов классного руководителя, построенная с использованием CASE-средства BPwin, представлена в приложении
    (см. Приложение 1).

    Следующим шагом является детализация контекстного процесса с помощью диаграммы верхнего уровня. Эта диаграмма содержит в себе четыре процесса:

    1. анализ;

    2. написание плана КР;

    3. проверка плана КР (см. Рисунок 1).



    Рисунок 1 – Детализация процесса «ООШ»

    Таким образом, основными бизнес-процессами являются: анализ, написание плана КР, проверка плана КР.

    1.3 Требования к проектируемой БД


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

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

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

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

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

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

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

    Структура базы данных должна обеспечивать:

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

    2. минимальное время обработки данных;

    3. минимальную избыточность данных;

    4. надежность хранения информации в течение требуемого срока;

    5. достоверность данных [9, с.150].

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

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

    Техническое обеспечение должно удовлетворять следующим требованиям:

    1. программное обеспечение должно быть совместимо с ОС Windows;

    2. БД должна работать на компьютерном оборудовании с
      Intel-совместимой архитектурой;

    3. пропускная способность канала доступа из сети к базе данных должны быть не ниже 1Гб;

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

    Требования к техническим средствам, выполнение которых позволит обеспечить желаемый уровень производительности базы данных и время реакции системы на запрос пользователя при одновременном количестве запросов (в пределах 3 с. при 10 одновременно обрабатываемых запросах).

    Описание предметной области осуществляется с помощью
    CASE-средства автоматизации проектирования, логическая и физическая модель разработана с помощью ErStudio 8.1 [1, с.160].

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

    Таким образом, требуется спроектировать базу данных для АРМ классного руководителя, которая должна выполнять следующие функции:

    1. просмотр информации по заданным критериям;

    2. ввод информации с документов при помощи клавиатуры;

    3. анализ данных;

    4. редактирование данных и манипулирование ими;

    5. накопление и хранение данных;

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

    7. просмотр предварительного результата работы;

    8. получение справок по запросам.

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

    2 Проектная часть

    2.1 Концептуальное проектирование

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

    В процессе ее разработки должны быть определены:

    1. типы сущностей;

    2. типы связей;

    3. атрибуты;

    4. домены атрибутов;

    5. потенциальные ключи;

    6. первичные ключи [20].

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

    Тип сущности – представляет собой множество объектов реального мира с одинаковыми свойствами. Тип сущности характеризуется независимым существованием и может быть объектом с физическим (реальным) существованием или объектом с концептуальным (абстрактным) существованием.

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

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

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

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

    Сущность может иметь несколько различных ключей.

    Модель «сущность – связь» основана на диаграммной технике. Для представления различных аспектов структуры данных используются графические средства. В нотации Чена сущности изображаются прямоугольником, внутри которого помещается имя сущности. Прямоугольник, соответствующий слабой сущности, обводится двойной рамкой. Атрибуты изображаются в виде овала, соединенного с соответствующим прямоугольником. Ключевые атрибуты выделяются подчеркиванием. Связь обозначается ромбом. Ромб окружен двойной линией, если связь задана между слабой сущностью и сущностью, от которой она зависит. Участники связи присоединены к ромбу линией. Для обозначения типа связи используются символы «1» и «М» (иногда вместо «М» применяют символ бесконечности или ставят одинарные и двойные стрелки). Двойная линия обозначает полное участие сущности в связи. Ассоциированные сущности изображаются ромбом, заключенным в прямоугольник [10, c.130].

    Для создания ER-модели необходимо выделить сущности предметной области:

    1. Учебное заведение. Атрибуты: Название, Адрес, Телефон.

    2.Преподаватель. Атрибуты: ФИО, Логин, Пароль, Предмет.

    3. Предмет. Атрибуты: Название, Преподаватель.

    4. Ученик. Атрибуты:№ в журнале, ФИО, Дата рождения, Номер телефона.

    5. Ученик/предмет. Атрибуты: Ученик/предмет, Название предмета, Дата проведение, Оценка (см. Рисунок 2).



    Рисунок 2 – Модели стержневых сущностей

    Между отношениями реализуется связь типа 1 : М (один-ко-многим),
    1 : 1 (один к одному),через внешний ключ. Ключ вводится для того отношения, к которому осуществляется множественная связь. Внешнему ключу соответствует первичный или уникальный ключ основного (родительского) отношения[16].

    Исходя из выявленных сущностей, построим ER-диаграмму предметной области (см. Приложение 2).

    Таким образом, опираясь на представленное выше описание предметной области, были определены основные понятия ER-модели: сущности, атрибуты и связи между ними. Исходя из имеющихся данных, была построена
    ER-диаграмма, необходимая для дальнейшего проектирования информационной системы.

    2.2 Логическое проектирование

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

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

    Если концептуальная модель данных не зависит от любых физических аспектов реализации, то логическая модель данных создается на основе выбранной модели организации данных целевой СУБД. Иначе говоря, на этом этапе уже должно быть известно, какая СУБД будет использоваться в качестве целевой – реляционная, сетевая, иерархическая или объектно-ориентированная. Однако на этом этапе игнорируются все остальные характеристики выбранной СУБД, например, любые особенности физической организации ее структур хранения данных и построения индексов [18].

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

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

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

    2.3 Физическое проектирование


    В техническом задании указаны рекомендуемые средства разработки, это пакет MSOffice 2010 и новее, в состав которого входит СУБД Access. Все версии СУБД позволяют преобразовывать форматы базы данных, но не всегда все объекты преобразуются корректно. Поэтому целесообразно в целях экономии средств и во избежание сложностей преобразования форматов рекомендовать ту версию СУБД, которая имеется у заказчика. Если заказчик не имеет современной версии Office, то разработку можно вести в любой версии и при передаче базы данных заказчику следует установить на его компьютере бесплатную среду выполнения Access.

    MSAccess является признанным лидером для создания и ведения небольших баз данных, с ограниченным количеством пользователей, небольшой группой (до 10 человек). Самые важные особенности – это удобный интерфейс, достаточно высокая производительность и широкие возможности для построения приложений в той же среде, что и база данных.

    База данных в СУБД ACCESSиспользует реляционную модель данных,
    т.е. вся информация в БД хранится в таблицах. В таблицах данные распределяются по столбцам и строкам. Отдельная ячейка таблицы называется полем [17].

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

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

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

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

    В нашей БД стержневые сущности: «Учебное заведение», «Преподаватель», «Предмет», «Ученик», «Ученик/предмет».

    Назначаем для каждой сущности первичный ключ: Ученик – № в журнале, Преподаватель – Логин, Предмет – Название.

    Для изображения модели структуры базы данных применяем диаграмму IDEF1x, на ней атрибуты записываются внутри прямоугольника сущности, а имя сущности пишут над прямоугольником[18].

    Каждая из сущностей в реляционной базе данных отображается в виде таблицы. При проектировании таблиц рекомендуется руководствоваться следующими основными принципами:

    1. каждая таблица состоит из однотипных строк и имеет уникальное имя;

    2. строки имеют фиксированное число полей (столбцов) и значений (множественные поля и повторяющиеся группы недопустимы), т.е. в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего;

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

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

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

    6. при выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию [9, c.140].

    Структура спроектированных таблиц БД показана в таблицах
    (см. Таблицы 1–5).

    Таблица 1.

    Описание структуры записей таблицы «Учебное заведение»




    Имя поля

    Тип поля

    Размер поля

    Примечания

    1

    Название

    Текстовый

    50

    Первичный ключ

    2

    Адрес

    Текстовый

    50




    3

    Телефон

    Числовой

    50





    Таблица 2.

    Описание структуры записей таблицы «Преподаватель»




    Имя поля

    Тип поля

    Размер поля

    Примечания

    1

    ФИО

    Текстовый

    50




    2

    Логин

    Текстовый

    50

    Первичный ключ

    3

    Пароль

    Дата/время

    50




    4

    Предмет

    Текстовый

    50

    Вторичный ключ


    Таблица 3.

    Описание структуры записей таблицы «Предмет»




    Имя поля

    Тип поля

    Размер поля

    Примечания

    1

    Название

    Числовой

    50

    Первичный ключ

    2

    Преподават-ель

    Текстовый

    50





    Таблица 4.

    Описание структуры записей таблицы «Ученик»




    Имя поля

    Тип поля

    Размер поля

    Примечания

    1

    № в журна-ле

    Текстовый

    50

    Первичный ключ

    2

    ФИО

    Текстовый

    50




    3

    Дата рождения

    Текстовый

    50




    4

    Номер телефона

    Дата/время

    50





    Таблица 5.

    Описание структуры записей таблицы «Ученик/предмет»




    Имя поля

    Тип поля

    Размер поля

    Примечания

    1

    Название предмета

    Текстовый

    50

    Первичный ключ

    2

    Дата прове-дение

    Текстовый

    50

    Первичный ключ

    3

    Оценка

    Дата/время

    50

    Первичный ключ


    В результате проектирования получилась схема БД АРМ классного руководителя для СУБД ACCESSв интегрированной среде
    (см. Рисунок 3).



    Рисунок 3 – Схема БД АРМ классного руководителя

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

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

    В данной курсовой работе спроектирована АРМ классного руководителя, проанализирована и описана предметная область. Были выявлены основные функции и операции, которые выполняет классный руководитель, а также определены основные пользователи будущей АРМ. По результатам анализа предметной области выявлены основные сущности и связи между ними, построена концептуальная модель данных в виде диаграммы «сущность-связь».

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

    При необходимости разработанное проектное решение для базы данных АРМ классного руководителя может легко дополняться и позволяет решать все задачи, сформулированные в задании на курсовую работу. Его реализацию можно осуществить в любом СУБД. Это позволяет сделать вывод, что задание выполнено полностью. Таким образом, задачи проектирования базы данных для АРМ классного руководителя полностью выполнены.

    Список использованных источников

    Литература

    1. Атре, Ш. А. Структурный подход к организации баз данных /
      Ш. А. Атре. – М. : Финансы и статистика, 2017. – 320 с.

    2. Бакаревич, Ю. Б. Самоучитель MicrosoftAccess 2016 / Ю. Б. Бакаревич, Н. В. Пушкина. – СПб. : БХВ-Петербург, 2020. – 387 c.

    3. Бойко, В. В. Проектирование баз данных информационных систем /
      В. В. Бойко, В. М. Савинков. – М. : Финансы и статистика, 2016. – 351 с.

    4. Гилуа, М. М. Множественная модель данных в информационных системах / М. М. Гилуа. – М. : Наука, 2016. – 312 с.

    5. Голосов, А. О. Реляционные базы данных / А. О. Голосов. – М. : Форум, 2016. – 176 с.

    6. Дейт, К. P. Руководство по реляционной СУБД / К. Р. Дейт. – М. : Финансы и статистика, 2018. – 573 с.

    7. Дейт, К. Д. Введение в системы баз данных / К. Д. Дейт. – М. : Финансы и статистика, 2016. – 1328 с.

    8. Джексон Г. Д. Проектирование реляционных баз данных для использования с микро ЭВМ / Г. Д. Джексон. – М. : Мир, 2018. – 252 с.

    9. Джен, Л. Х. Проектирование реляционных баз данных просто и доступно /Л. Х. Джен. – M. : Лори, 2017. – 230 с.

    10. Диго, С. М. Проектирование и использование БД / С. М. Диго. – М. : Финансы и статистика, 2016. – 208 с.

    11. Мартынов, К. В. Организация баз данных / К. В. Мартынов. –
      М. : Мир, 2018. – 250 с.

    12. Цикритизис, Ф. Н. Модели данных / Ф. Н. Цикритизис. – М. : Финансы и статистика, 2018. – 290 с.



    Электронные ресурсы

    1. Cайт МБОУ «Октябрьская ООШ» [Электронный ресурс]. – [2021]. – Режим доступа : https://www.oktich.schoolrm.ru. – Загл. с экрана.

    2. Классификация баз данных [Электронный ресурс]. – [2021]. – Режим доступа : http://www.cs.karelia.ru. – Загл. с экрана.

    3. О создании ER-диаграмм [Электронный ресурс]. – [2020]. – Режим доступа : http://inf-teh-lotos.ru. – Загл. с экрана.

    4. О создании БД [Электронный ресурс]. – [2020]. – Режим доступа : https://gigabaza.ru. – Загл. с экрана.

    5. Основные функции СУБД [Электронный ресурс]. – [2021]. – Режим доступа : http://www.cs.citforum.ru. – Загл. с экрана.

    6. Система управления базами данных (СУБД), назначение и основные функции [Электронный ресурс]. – [2021]. – Режим доступа : http://www.infosgs.narod.ru. – Загл. с экрана.

    7. Система управления базами данных [Электронный ресурс]. – [2021]. – Режим доступа : http://www.wikipedia.org. – Загл. с экрана.

    8. Уроки создания БД [Электронный ресурс]. – [2021]. – Режим доступа : https://site-do.ru. − Загл. с экрана.


    Приложение 1

    Контекстная диаграмма IDEF0 «Работа классного руководителя»



    Рисунок 1.1 – Контекстная диаграмма IDEF0 «Работа классного руководителя»















    Приложение 2


    ER–диаграмма предметной области «Классный руководитель»



    Рисунок 2.1 – ER–диаграмма предметной области «Классный руководитель»

    Приложение 3

    Логическая модель БД АРМ классного руководителя


    Рисунок 3.1 – Логическая модель БД АРМ классного руководителя



    написать администратору сайта