Реферат Информационная система Деканата
Работа добавлена на сайт bukvasha.net: 2015-10-28Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
Министерство образования и науки Украины
Харьковский национальный университет радиоэлектроники
Кафедра информатики
Пояснительная записка
к КУРСОВОЙ РАБОТЕ
по курсу « Базы данных и информационные системы »
на тему « Информационная система Деканата »
Выполнила: Проверила:
ст. гр. Инф-03-3 доц. Алисейко Е.В.
Фёдорова Т.Н.
Харьков
2005
ПОСТАНОВКА ЗАДАЧИ
Необходимо разработать информационную систему, которая будет применятся в деканате университета при работе со студентами.
Входными данными являются: ФИО студента, дата рождения, адрес, факультет, специальность, год поступления, номер группы, номер зачетки, пройден медосмотр или нет, сдана флюрография или нет; ФИО преподавателя, должность, кафедра; название предмета, форма контроля ( экзамен или зачет ), дата сдачи, оценка.
С помощью данной информационной системы можно получить следущие сведения: о студентах не сдавших сесию, средний бал по предмету в группе, средний бал каждого студента, сдана ли флюрография и пройден ли мед.осмотр, также можно получить ведомости задолженностей по группе, предмету, преподавателю.
РЕФЕРАТ
Пояснительная записка к курсовой работе: 45 стр., 19 рис., 1 таблица,
3 раздела, 3 приложения, 8 источников.
Данный курсовой проект посвящен разработке информационной системы, позволяющей упростить и ускорить процесс обработки результатов сессии.
Практическая реализация выполнена с использованием СУБД MS ACCESS. Приведены программы построения отношений и запросов в среде реляционных моделей с использованием языка SQL2.
Разработаны проекты данных даталогической модели и занесены в таблицы средствами СУБД ACCESS, для обеспечения комфорта пользователя, построены отчеты и формы.
Ключевые слова и выражения: метод, предметная область, объект, модель данных, реляционная модель данных, база данных, информационная система, СУБД ACCESS, SQL2, отношение, функциональная зависимость, первичный ключ, потенциальный ключ, внешний ключ, нормализация, нормальная форма Бойса-Кодда, запрос, таблица, форма, отчет.
СОДЕРЖАНИЕ
ПОСТАНОВКА ЗАДАЧИ............................................................................... | 2 |
РЕФЕРАТ.......................................................................................................... | 3 |
ВВЕДЕНИЕ....................................................................................................... | 5 |
1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ…………………………………… | 8 |
1.1 Построение инфологической модели предметной области методом ER- диаграммы………………………………………………………………. | 8 |
1.2 Описание диаграммы «сущность-связь» для БД деканата факультета……………………………………………………………………. | 13 |
2 РАЗРАБОТКАСХЕМЫ БАЗЫ ДАННЫХ И ЕЕ НОРМАЛИЗАЦИЯ….. | 15 |
2.1 Ограничения целостности данных. Спецификация ограничений целостности РБД. Функциональные зависимости атрибутов. Ключи…… | 15 |
2.2 Нормализация логической схемы базы данных……………………... | 18 |
2.3 Описание логической схемы базы данных…………………………... | 18 |
3 РАЗРАБОТКА ПРОЕКТА ПРИЛОЖЕНИЯ……………………………... | 21 |
3.1 Описание данных БД “Деканат”…………………………………….. | 21 |
3.2 Создание отношений БД с помощью языка SQL……………………. | 23 |
3.3 Заполнение базы данных……………………………………………… | 28 |
3.4 Организация запросов к базе данных cредствами языка SQL……… | 28 |
3.5 Создание запросов к базе данных деканата факультета…………….. | 34 |
ЗАКЛЮЧЕНИЕ………………………………………………………………. | 39 |
СПИСОК ЛИТЕРАТУРЫ…………………………………………………… | 40 |
ПРИЛОЖЕНИЕ А…………………………………………………………… | 41 |
ПРИЛОЖЕНИЕ Б............................................................................................. | 43 |
ПРИЛОЖЕНИЕ В……………………………………………………………. | 45 |
ВВЕДЕНИЕ
История развития СУБД насчитывает более 30 лет. В 1968 году была введена в эксплуатацию первая промышленная СУБД система IMS фирмы IBM. В 1975 году появился первый стандарт ассоциации по языкам систем обработки данных – Conference of Data System Languages ( CODASYL ), который определил ряд фундаментальных понятий в теории систем баз данных, которые и до сих пор являются основополагающими для сетевой модели данных.
В дальнейшее развитие теории баз данных большой вклад был сделан американским математиком Э.Ф.Коддом, который является создателем реляционной модели данных.
Менее двух десятков лет прошло с этого момента, но стремительное развитие вычислительной техники, изменение ее принципиальной роли в жизни общества, обрушившийся бум персональных ЭВМ и, наконец, появление мощных рабочих станций и сетей ЭВМ повлияло также и на развитие технологии баз данных. Можно выделить четыре этапа в развитии данного направления в обработке данных. Однако необходимо заметить, что все же нет жестких временных ограничений в этих этапах: они переходят один в другой и даже сосуществуют параллельно.
Первый этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ типа PDP11, разных моделях HP. Базы данных хранились во внешней памяти центральной ЭВМ, пользователями этих баз данных были задачи, запускаемые в основном в пакетном режиме. Интерактивный режим доступа обеспечивался с помощью консольных терминалов, которые не обладали собственными вычислительными ресурсами (процессором, внешней памятью) и служили только устройствами ввода-вывода для центральной ЭВМ. Программы доступа к БД писались на различных языках и запускались как обычные числовые программы. Мощные операционные системы обеспечивали возможность условно параллельного выполнения всего множества задач. Эти системы можно было отнести к системам распределенного доступа, потому что база данных была централизованной, хранилась на устройствах внешней памяти одной центральной ЭВМ, а доступ к ней поддерживался от многих пользователей-задач.
Второй этап. Персональные компьютеры стремительно ворвались в нашу жизнь и буквально перевернули наше представление о месте и роли вычислительной техники в жизни общества. Каждый пользователь мог себя почувствовать полным хозяином этого мощного и удобного устройства, позволяющего автоматизировать многие аспекты деятельности. И, конечно, это сказалось и на работе с базами данных. Спрос на развитые удобные программы обработки данных заставлял поставщиков программного обеспечения поставлять все новые системы, которые принято называть настольными (desktop) СУБД. Значительная конкуренция среди поставщиков заставляла совершенствовать эти системы, предлагая новые возможности, улучшая интерфейс и быстродействие систем, снижая их стоимость. Наличие на рынке большого числа СУБД, выполняющих сходные функции, потребовало разработки методов экспорта-импорта данных для этих систем и открытия форматов хранения данных.
Третий этап. Хорошо известно, что история развивается по спирали, поэтому после процесса «персонализации» начался обратный процесс – интеграция. Множится количество локальных сетей, все больше информации передается между компьютерами, остро встает задача согласованности данных, хранящихся и обрабатывающихся в разных местах, но логически друг с другом связанных, возникают задачи, связанные с параллельной обработкой транзакций – последовательностей операций над БД, переводящих ее из одного непротиворечивого состояния в другое непротиворечивое состояние. Успешное решение этих задач приводит к появлению распределенных баз данных, сохраняющих все преимущества настольных СУБД и в то же время позволяющих организовать параллельную обработку информации и поддержку целостности БД.
Четвертый этап характеризуется появлением новой технологии доступа к данным – интранет. Основное отличие этого подхода от технологии клиент-сервер состоит в том, что отпадает необходимость использования специализированного клиентского программного обеспечения. Для работы с удаленной базой данных используется стандартный броузер Интернета, например Microsoft Internet Explorer или Netscape Navigator. При этом встроенный в загружаемые пользователем HTML-страницы код, написанный обычно на языке Java, Java-script, Perl и других, отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к базе данных, выполняя, таким образом, ту работу, которой в технологии клиент-сервер занимается клиентская программа. Удобство данного подхода привело к тому, что он стал использоваться не только для удаленного доступа к базам данных, но и для пользователей локальной сети предприятия. Простые задачи обработки данных, не связанные со сложными алгоритмами, требующими согласованного изменения данных во многих взаимосвязанных объектах, достаточно просто и эффективно могут быть построены по данной архитектуре. В этом случае для подключения нового пользователя к возможности использовать данную задачу не требуется установка дополнительного клиентского программного обеспечения. Однако алгоритмически сложные задачи рекомендуется реализовывать в архитектуре «клиент-сервер» с разработкой специального клиентского программного обеспечения.
У каждого из вышеперечисленных подходов к работе с данными есть свои достоинства и свои недостатки, которые и определяют область применения того или иного метода, и в настоящее время все подходы широко используются.
1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Построение инфологической модели предметной области методом.
Первым шагом проектирования является общая постановка задачи, анализ предметной области и построение инфологической модели предметной области. Модель данных «сущность-связь», или ER-модель (от английских entity -сущность и relationship - связь) предложена в 1976 П. Ченом и с тех пор неоднократно подвергалась пересмотру и модификации как малоэффективная модель в проектировании баз данных, однако диаграмма, строящаяся при проектировании с помощью модели данных «сущность-связь», полезна при проектировании даталогической схемы.
Диаграмма Чена (диаграмма сущность/связь), используемая в модели сущность/связь, используется и сейчас, так как ее наглядность помогает дальнейшему логическому программированию и начальной нормализации РБД. Известно, что в логической схеме РБД семантика данных передается посредством первичных и внешних ключей, функциональных зависимостей. Общий подход к проблеме семантического моделирования характеризуется четырьмя основными этапами:
Ø прежде всего следует задать множество семантических концепций (понятий),которые полезны при неформальном моделировании предметной области;
Ø далее нужно определить множество соответствующих формальных объектов,которые могут быть использованы для представления описанных выше семантических концепций;
Ø нужно вывести множество формальных правил целостности для работы с такими формальными объектами;
Ø следует задать множество формальных операторов для работы с этими формальными объектами.
Объекты, правила и операторы вместе образуют расширенную модель данных, если эти конструкции действительно являются супермножеством конструкций одной из базовых моделей, таких как, например, базовая реляционная модель.
«Концептуальное понимание» ПО так же, как «концептуальное понимание» соответствующей РБД должны описываться некоторым формализованным образом. Средством такого описания служат инфологические модели. Термин «инфологическая модель» может быть применен как к моделированию данных, так и к моделированию собственно предметной области (ПО). Различие здесь может быть весьма существенным, хотя иногда эти два уровня моделирования «сливаются» в один. В информационно-логических моделях акцент делается на «устройстве» ПО и «логике» ее функционирования, тогда как информационные аспекты играют лишь вспомогательную роль. Инфологические модели данных (ИЛМД) предназначены для решения куда более скромных задач, сводящихся к построению эффективной в некотором смысле совокупности хранимых данных и процессов их обработки. Для «семантически окрашенного» структурирования данных в моделях данных используется два основных вида абстракций - обобщение и агрегация.
Обобщение - это вид абстракции, позволяющей соотнести множество объектов данных (знаков) с одним общим для них типом или множество типов -с супертипом. (Обобщение «знак-тип» называется классификацией). Подобным образом в модели определяется иерархия типов. Если обобщающий тип обладает некоторыми свойствами, то этими же свойствами обладают подчиненные типы. Заметим, что в представлениях БД знак, находящийся на нижнем уровне иерархии типов, является расширением для всех обобщающих его типов. Процесс, обратный обобщению, также часто используется при семантическом моделировании. В случае «тип-подтип» он называется классификацией; в случае «тип-знак» - экземпляризацией.
Агрегация - это вид абстракции, посредством которой объект конструируется из других, базовых объектов. Агрегация может использоваться как на уровне знаков, так и на уровне типов, Например, в проектируемой схеме агрегация знаков 'Петренко', 'менеджер' порождает знак, соответствующий сотруднику (рассматриваемому как объект данных, моделирующий объект ПО). Агрегация, проведенная на уровне типов, индуцирует соответствующую агрегацию знаков объектов.
Процесс, обратный агрегации, называется пошаговой детализацией.
Абстракции обоих видов используются в сочетании друг с другом и позволяют конструировать новые типы на основе знаков или базовых типов. Абстракции позволяют также декомпозировать сложные объекты, уточняя их семантику посредством подчиненных типов или базовых агрегируемых объектов.
В модели выделяются два вида объектов ПО - сущности и связи. Объекты наделяются свойствами, причем сущности рассматриваются как агрегаты свойств, а связи - как агрегаты сущностей и, может быть, собственных свойств. Граница между этими категориями подчас оказывается весьма размытой.
При построении семантической модели РБД следует учитывать следующие основные правила структурирования в ER-модели: свойство всегда связано с одним определенным типом объектов, т.е. одно и то же свойство не может характеризовать несколько типов (если только они не являются подчиненными общему типу); одни и те же объекты-сущности могут агрегироватся в любое количество связей; сущность может агрегироваться в некоторой связи несколько раз (в этом случае каждое вхождение сущности в связь характеризуется ее ролью в этой связи); связи могут агрегировать в себе любое количество сущностей (равное или большее двух).
Связи не могут агрегировать связи. Число сущностей, агрегированных в связь, называется степенью связи. Если степень связи равна п, говорим, что это n-арная связь; при п=2 связь называется бинарной, при п=3 - тернарной.
Свойства в ER-модели могут быть простыми (подобно атрибутам РМД) или агрегатными. ( агрегат свойств ). Свойства могут быть однозначными, имеющими одно скалярное значение для каждого объекта, или многозначными, имеющими несколько скалярных значений. Аналогом домена РМД служит множество (скалярных) значений. Каждое свойство ассоциируется с типом сущности или связи путем задания отображения от объекта к множеству значений.
Формально структурная спецификация ER-модели задается следующим образом. Прежде всего, вводится множество Е={Е1,...,Еm} типов сущностей, где Ei={ei1,..., еiMі} - множество сущностей. Введем теперь множество R={R1,..., Rp} типов связей. Пусть (Е1,..., Еn) - совокупность сущностей (не обязательно различных), агрегируемых в n-арную связь Rj, Lj={lj1,...,ljn} - множество ролей каждого типа сущности Ek в типе связи Rj. Тогда Rj={(lj1/e1,..., ljn/en) | е1єЕ1,..., еnєЕn}, где ljk/ek обозначает поименованную ролью ljk сущность ek. Поскольку сущности в связи сопровождаются своей ролью, порядок их расположения не значим. По аналогии с РМД множества Е и R считаются конечными, но не фиксируются.
Пусть теперь Vi ,..., Vn - множества скалярных значений. Многозначное агрегатное свойство можно определить как отображение φi:Еi—»(V1х...хVк)q или φj: Rj—»(V1x...xVk)q, где k - число агрегированных простых свойств, показатель декартовой степени q - число повторений агрегата. При k =1 получаем простое свойство. При q =1 свойство является однозначным.
Наиболее распространенным видом представления схемы БД в ER-модели является ER-диаграмма. Это граф с тремя видами вершин: вершины-прямоугольники обозначают типы сущностей, вершины-ромбы - типы связей, вершины-овалы - множества значений (домены). Внутри вершины записывается соответствующее имя. Обычно фиксируется два вида именованных ребер. Ребра «сущность-связь» обозначают соответствующую агрегацию и имя ребра представляет роль сущности в связи. Ребра «объект-множество значений» соответствуют свойствам объекта. Ребра-свойства могут «ветвиться», образуя в общем случае направленный граф, показывающий иерархию имен агрегатов свойств. Двойным ребром на диаграмме обозначается многозначное свойство. При отображении каждый объект представляется реляционной таблицей.
Согласно определению, данному Ченом, объектом называется «предмет, который может быть четко идентифицирован». При этом объекты подразделяются на правильные и слабые объекты. Слабым объектом называется объект, который находится в зависимости от некоторого другого объекта, т. е. он не может существовать, если не существует этот другой объект. Правильным называется объект, который не является слабым. Вместо термина «правильный объект» иногда используют термин «сильный объект».
В диаграмме каждый тип объекта показан в виде отдельного прямоугольника с его именем внутри, причем слабые типы объектов изображают в двойной рамке.
Объекты (и отношения) обладают некоторыми свойствами. Все объекты одного типа обладают некоторыми общими свойствами. Опишем некоторые виды свойств и их особенности:
а) простое или составное свойство;
б) ключевое свойство (уникальное в некотором контексте);
в) однозначное или многозначное свойство;
г) отсутствующее свойство («неизвестное» или «неприменимое»);
д) базовое или производное свойство.
Свойства показываются в виде эллипсов с названием свойства, записанного внутри него. Эллипсы соединены сплошной линией с соответствующим объектом. Эллипс обведен штриховой линией, если свойство производное и двойной линией, если свойство многозначное. Если свойство составное, то составляющие его свойства показаны в виде других эллипсов, соединенных с эллипсом составного свойства с помощью дополнительных линий. Ключевые свойства, как правило, подчеркиваются, а множества их значений не показываются вовсе. В диаграмме сущность-связь отношение определяется как «ассоциация объектов».
Существует принципиальная разница между типами и экземплярами отношений, однако при неформальном описании такими тонкостями можно пренебречь. Объекты, включенные в данное отношение, называются участниками данного отношения, а количество участников этого отношения называется степенью данного отношения.
Пусть R является типом отношения, которое содержит тип объекта Е находится, по крайней мере, в одном экземпляре отношения R, тогда участие Е в отношении R называется полным, в противном случае - частичным.
Отношения в модели сущность-связь могут иметь тип один-к-одному, один-ко-многим, многие-к-одному, многие-ко-многим.
Каждый тип отношения показан в виде ромба с названием отношения внутри. Ромб окружен двойной линией, если отношение задано между слабым типом объекта и типом объекта, от существования которого находится в зависимости слабый тип объекта.
Участники каждого отношения присоединены к соответствующему отношению сплошными линиями. Каждая такая линия содержит надпись «1» или «N» для обозначения типа отношения. Двойная линия обозначает полное участие.
1.2 Описание диаграммы «сущность-связь» для предметной области деятельности организации.
Сильными объектами являются Студент, Преподаватель, Предметы.
Свойством объекта Студент является ФИО, дата рождения, адрес, факультет, специальность, год поступления, номер группы, мед.осмотр, флюрография, номер зачётки.
Свойствами объекта Предметы являются название, форма контроля, № преподавателя, дата сдачи, № предмета.
Объекты Студент, Предметы связаны отношениями сдает зачет, сдает экзамен.
Объекты Преподаватель, Предметы связаны отношением препадает.
Инфологическая схема (ER-диаграмма) предметной области показана на рисунок 1.1.
2 РАЗРАБОТКА СХЕМЫ БАЗЫ ДАННЫХ И ЕЕ НОРМАЛИЗАЦИЯ
2.1 Ограничения целостности данных. Спецификация ограничений целостности в РБД. Функциональные зависимости атрибутов. Ключи.
Отобразим инфологическую схему предметной области в даталогическую модель РБД. При этом каждому объекту предметной области соответствует отношение РБД, находящееся по крайней мере в первой нормальной форме с последующей оптимизация схем отношений с учетом функциональных зависимостей и потенциальных ключей отношений до нормальной формы Бойса - Кодца.
Известно, что при столкновении с проблемами эффективной обработки больших объемов данных и интеграции новых представлений о структуре данных в действующую информационную систему для исправления ошибок, допущенных на начальных стадиях разработки становится необходимым проведение работ по реорганизации БД. Теория функциональных зависимостей (F-зависимостей) помогает избежать этих проблем и дает представление о том виде БД, при котором обеспечивается наибольшая эффективность ее функционирования.
Определение F-зависимости. Известно, что когда мы говорим, что в DB-отношении выполняется зависимость X—>Y, имеем в виду, что каждый экземпляр р; отношения Р;, появляющийся в БД в процессе ее функционирования, отвечает условию "Y функционально зависит от X" . F-зависимости не могут быть вычислены на основании анализа экземпляров отношения в БД. Для этого необходимо анализировать все множество "допустимых экземпляров", для чего предлагается провести логический анализ предметной области БД. Теория F-зависимостей базируется на том, что в каждом DB-отношении между F-зависимостями существуют фундаментальные закономерности, с помощью которых можно выводить одни зависимости из других. Множество зависимостей, которые можно вывести из F называется замыканием F- F+. Известно, что схема БД a=(R,F) (носитель отношения, множество F-зависимостей) фактически задает множество ограничений. Теория F-зависимостей разработана для поиска "наименьших" множеств ограничений из класса эквивалентных множеств. Поддержка каждого ограничения при функционировании БД связана с выполнением дополнительных операций при введении в БД решение проблемы членства, т.е. решение вопроса, выводится ли новых кортежей отношений. Следовательно, минимизация числа поддерживаемых ограничений целостности приводит к уменьшению объема памяти, нужной для хранения отношения. Важным шагом в решении этой проблемы является заданная зависимость g из заданного множества F. При решении этой проблемы можно любым способом построить F+, а потом узнать, принадлежит ли зависимость замыканию F+, но построение F+ связано с перебором всех подмножеств множества F атрибутов носителя, что, к Однако правила целостности справедливы и для производных отношений (если к базовому отношению справедливо, например, правило: номер поставщика должен быть уникальным, то это справедливо и к каждой выборке строк этого отношения). Таким образом, правила целостности наследуются производными отношениями. Однако для производных отношений могут существовать дополнительные правила целостности либо противоречащие правила целостности базовых отношений. Таким образом, их необходимо задавать явно. Примером может служить определение базового ключа для представления.
Первичный ключ есть частный случай потенциального ключа. Потенциальный ключ К для отношения R это подмножество атрибутов R, обладающих свойствами уникальности(нет двух различных кортежей в R с одинаковым знанием К) и неизбыточности ( ни какое из подмножеств К не обладает свойствами уникальности).
Каждое отношение имеет, по крайней мере, один потенциальный ключ (РК), состоящий из подмножества всех атрибутов. Либо эта комбинация будет обладать свойствами не избыточности и будет единственным потенциальным ключом, либо существует по крайней мере одно подходящее подмножество этой комбинации заведомо обладающее свойством уникальности и к тому же обладающее свойством неизбыточности.
Если R переменная отношения, тогда потенциальный_ключ К для R есть подмножество R, всегда обладающее свойствами уникальности ( нет двух различных кортежей в текущем значении переменной R с одинаковым значением К) и неизбыточности ( никакое из подмножеств К не обладает свойством уникальности).
В отношении может быть несколько потенциальных ключей. Потенциальный ключ, состоящий более чем из одного атрибута, называется составным. Потенциальный ключ, состоящий из одного атрибута, называется простым.
(Иногда неизбыточность называется минимальностью). Потенциальные ключи обеспечивают основной механизм адресации на уровне кортежей. Один из потенциальных ключей может быть выбран в качестве альтернативного ключа. Базовое отношение всегда должно иметь первичный ключ.
Внешний ключ FK в отношении R2 есть подмножество атрибутов R2, такое, что существует базовое отношение Rl (R1 и R2 различны) с потенциальным ключом СК и каждое подмножество FK в текущем значении R2 всегда совпадает со значением СК некоторого кортежа в текущем значении R1.
Таким образом, каждое значение внешнего ключа в R2 есть значение потенциального ключа в R1 и они определены на одном домене. Внешний ключ FK может не быть частью первичного ключа в R2.
Поддержание внешних ключей и поддержание ссылочной целостности это одно и тоже. РБД не должна содержать несогласованных значений внешних ключей, то есть не должно быть значений внешнего ключа, для которого не существует соответствующего ему значение потенциального ключа.
2.2 Нормализация логической схемы базы данных.
Отношение находится в первой нормальной форме ( 1НФ ) ,если значения атрибута атомарны. Отношение находится во второй нормальной форме ( 2НФ ) если оно находится в 1НФ и каждый неключевой атрибут неприводимо зависим от первичного ключа. Отношение в 1НФ всегда можно свести к эквивалентному набору отношений в 2НФ. Отношение находится в ЗНФ тогда и только тогда, когда оно находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.
Пусть отношение имеет не один потенциальный ключ (первичный), т.е. отношение имеет два или более потенциальных ключа. Потенциальные ключи могут быть сложными и иметь общие атрибуты. В этом случае определение ЗНФ заменяется более строгим - нормальной формой Бойса-Кодда (НФБК). В случае одного потенциального ключа определение ЗНФ и НФБК эквивалентны (левая и правая часть записи функциональной зависимости ( ФЗ ) называются соответственно детерминантом и зависимой частью). Отношение находится в НФБК, если каждая нетривиальная неприводимая слева ФЗ обладает потенциальным ключом в качестве детерминанта. Под детерминантой понимаем некоторый атрибут, возможно составной, от которого какой-либо другой атрибут зависит функционально полно. Зависимость называется нетривиальной, если правая часть зависимости является подмножеством левой. Множество ФЗ называется неприводимым, если правая часть является одноэлементным множеством. Левая часть (детерминант) каждой ФЗ множества S является неприводимой, т.е. ни один атрибут не может быть опущен из детерминанта без изменения замыкания ST (неприводимость слева).
2.3 Описание логической схемы базы данных.
В представляемой БД “Деканат” содержится информация, использующаяся в университете. РБД состоит из отношений Студент, Преподаватели, Предметы.
Отношение Студент содержит по одному кортежу на каждого из студента и состоит из атрибутов ФИО – фамилия , имя , отчество студента, дата_рожд – дата рождения, адрес, факультет, специальность, год_поступления, номер_группы, мед_осмотр, флюрогр, №зачетки . Первичный ключ отношения – атрибут №зачетки.
Отношение Препод состоит из атрибутов №препод,ФИО – фамилия , имя, отчество преподавателя, должн – должность преподавателя, кафедра. Первичный ключ отношения – атрибут №препод.
Отношение Предмет состоит из атрибутов №предм, название, форма_контр, №препод, дата_сдачи. Первичный ключ отношения – атрибут №предм.
Отношение СдачаЗач состоит из атрибутов №зачетки, №предм, сдал_несд, дата_сдачи.
Отношение СдачаЭкз состоит из атрибутов Код, №зачетки, №предм, дата_сдачи, оценка. Первичный ключ отношения – атрибут Код.
Логическая схема РБД имеет вид:
Студент
| ФИО | дата_рожд | адрес | |
| факультет | специальность | год_поступления | |
| №группы | мед_осмотр | флюрогр | |
| №зачетки | |||
Предметы
| №предм | название | форма_контр |
| №препод | дата_сдачи | |
Преподаватели
| №прпод | ФИО | должн | кафедра |
СдачаЗач
| №зачетки | №предм | сдал_несд | дата_сдачи |
СдачаЭкз
| Код | №зачетки | №предм | дата_сдачи | оценка |
3 РАЗРАБОТКА ПРОЕКТА ПРИЛОЖЕНИЯ
3.1 Описание данных.
Таблица 1
| Элемент данных | Описание | Объект | Тип данных | Условие на значение | |||||
| ФИО | Фамилия и инициалы студента | Студент | Текстовый | Обязательное | |||||
| Дата_рожд | Дата рождения студента | Студент | Числовой | Обязательное | |||||
| Адрес | Адрес студента | Студент | Текстовый | Обязательное | |||||
| Факультет | Факультет обучения студента | Студент | Текстовый | Обязательное | |||||
| Специальн ость | Специальность обучения студента | Студент | Текстовый | Обязательное | |||||
| Год_поступления | Год_поступления студента | Студент | Числовой | Обязательное | |||||
| №группы | №группы студента | Студент | Числовой | Обязательное | |||||
| Мед_осмотр | Мед.осмотр | Студент | Логический | Обязательное | |||||
| Флюрогр | Флюрография | Студент | Логический | Обязательное | |||||
| №зачетки | Номер зачётки студента | Студент | Числовой | Обязательное (ключ) | |||||
| №предм | Номер предмета | Предмет | Числовой | Обязательное (ключ) | |||||
| Название | Название | Предмет | Текстовый | Обязательное | |||||
| Форм_контр | Форма контроля | Предмет | Текстовый | Обязательное | |||||
| №препод | Номер преподавателя | Предмет | Числовой | Обязательное | |||||
| Дата_сдачи | Дата сдачи | Предмет | Числовой | Обязательное | |||||
| №препод | Номер преподавателя | Препод | Числовой | Обязательное ( ключ ) | |||||
| ФИО | ФИО преподавателя | Препод | Текстовый | Обязательное | |||||
| Должн | Должность | Препод | Текстовый | Обязательное | |||||
| Кафедра | Кафедра | Препод | Текстовый | Обязательное | |||||
| №зачетки | Номер зачетки | СдачаЗач | Числовой | Обязательное | |||||
| №предм | Номер предмета | СдачаЗач | Числовой | Обязательное | |||||
| Сдал_несд | Сдал /не сдал зачет | СдачаЗач | Логический | Обязательное | |||||
| Дата_сдачи | Дата сдачи | СдачаЗач | Числовой | Обязательное | |||||
| Код | Код | СдачаЭкз | Числовой | Обязательное ( ключ ) | |||||
| №зачетки | Номер зачетки | СдачаЭкз | Числовой | Обязательное | |||||
| №предм | Номер предмета | СдачаЭкз | Числовой | Обязательное | |||||
| Дата_сдачи | Дата сдачи | СдачаЭкз | Числовой | Обязательное | |||||
| Оценка | Оценка за экзамен | СдачаЭкз | Числовой | Обязательное | |||||
3.2 Создание отношения БД с помощью языка SQL.
В
Язык SQL стал открытой собственностью IBM. На его основе IBM разработала для больших вычислительных машин реляционные СУБД: System R и DB2. Однако версии языка SQL в этих СУБД значительно различались.
Еще до выхода на рынок программного обеспечения коммерческих продуктов IBM компания Relation Software Inc. (ныне это Oracle Corporation) объявила о выпуске реляционной СУБД ORACLE, основанной на языке SQL. Уже тогда система ORACLE стала одной из доминирующих коммерческих СУБД. Предваряя многоплатформенную стандартизацию SQL, Oracle Corporation осуществила в течение нескольких лет перенос своего флагманского продукта на множество различных аппаратных и программных платформ - от ПК до больших вычислительных систем. Пути поставщиков ранних реляционных СУБД для мини-ЭВМ разошлись. Такие крупные разработчики как Oracle Corporation и ранние лидеры рынка СУБД для UNIX:Uniry Corp. и Informix Corp. использовали язык SQL для мини-ЭВМ. В СУБД Ingres компании Relational Technology, шс.(ныне Ingres Corp.) использовался язык QUEL. Позже язык был назван QBE (Query by Example) - язык запросов по образцу. Это мощный реляционный язык, основанный на языке реляционного исчисления. Позднее Ingres Corp. ввела в СУБД Ingres поддержку языка SQL.
В 80-х г. г. SQL стал доминирующим языком в среде реляционных СУБД для ЭВМ среднего класса и больших вычислительных машин. На персональные компьютеры SQL пришел в результате адаптации СУБД, разработанных для больших и средних ЭВМ.По мере пополнения рынка новыми коммерческими программными продуктами, основанными на реляционной модели, появлялись новые языковые средства обработки отношений. Для ПК доминирующим языком баз данных стал язык, разработанный компанией Ashton-Tate в семействе продуктов dBase (dBase II и III, а позднее - dBase III+, dBase IV). В настоящее время компанией Borland, поглотившей Ashton-Tate, выпущен ряд последующих версий этой системы. Даже после реализации SQL на ПК в середине 80-х гг. язык dBase остался главным языком на платформе ПК.Конкуренты компании Ashton-Tate - Fox Software и Nantucket Corp. -приняли некоторые собственные варианты языка dBase, и в начале 90-х гг. получила признание новая категория реляционных языков баз данных (в дополнение к SQL): язык Xbase. В
Команды создания таблиц (команды класса DDL)
Структура таблицы во всех диалектах языка SQL, создается командой CREATE TABLE.
CREATE TABLE < Имя таблицы > (< Имя столбца > < Тип данных >[(< Размер >)] [< Ограничения на столбец >], < Имя столбца > < Тип данных >[(< Размер >)],...,
< Имя столбца > < Тип данных > [(< Размер >)],..., < Ограничения на таблицу > (< Имя столбца >[,< Имя столбца >... ])...)
Различают следующие виды ограничений:
1) ограничения на столбец - средство обеспечения целостности домена и табличной целостности;
2) ограничения на таблицу - средство обеспечения ссылочной целостности БД. Объявление ограничений выполняется следующим образом: ограничения на значения данных указываются после определения столбца, ограничения на таблицу указываются после определения последнего столбца.
Модификация структуры таблицы выполняется командой ALTER TABLE. Команда не является частью стандарта ANSI, однако широко применяется в СУБД. Обычно команда используется для добавления, удаления, изменения размеров столбцов и их ограничений. Синтаксис команды, предназначенной для добавления столбца выглядит так.
ALTER TABLE < имя таблицы > ADD < имя столбца > < тип данных > <размер >.
По этой команде для существующих в таблице строк добавляется новый столбец, в который заносятся NULL значения. Новый столбец добавляется в конец таблицы. При добавлении нескольких столбцов их имена и определения отделяются запятыми. Команда является нестандартной, поэтому каждый раз при необходимости работы с ней надо обращаться к документации конкретной СУБД.
Если СУБД не поддерживает эту команду, то для изменения структуры заполненной данными таблицы рекомендуется создать новую структуру, а затем ее заполнить из старой таблицы командой INSERT с подзапросом SELECT. Удаление таблицы может выполнить только ее владелец. Перед удалением таблицы ее необходимо предварительно очистить от данных, затем можно удалить саму таблицу командой
DROP TABLE < имя таблицы >.
В пакете Access отношения БД создаются с использованием оболочки (создание таблиц средствами Access). Таблицы базы данных приведены в приложении 1.
Система формирует соответствующий DDL-запрос, посредством оператора CREATE TABLE. Создание отношений средствами SQL2 при помощи оператора CREATE TABLE является общим для всех типов коммерческих продуктов реляционного типа.
Ниже приводится построение таблицы БД «Деканат» с помощью оператора CREATE TABLE
CREATE TABLE Студенты (ФИО VARCHAR(50) NOT NULL, Номер_зач VARCHAR(50) NOT NULL, Специальность VARCHAR(50) NOT NULL, Группа VARCHAR(50) NOT NULL, Дата_рождения VARCHAR(50) NOT NULL, Адрес VARCHAR(50) NOT NULL, Год_поступления VARCHAR(50) NOT NULL, PRIMARY KEY (ФИО), FOREIGN KEY Р1(Номер_зач)
3.3 Заполнение базы данных.
Данные заносятся с использованием форм (Факультет, Преподаватели, Придметы) приведенных в приложении. При занесении данных следует обратить внимание на поддержание ограничений целостности по первичным и внешним ключам отношений согласно схеме базы данных.
Рекомендуется вначале установить связи в схеме базы данных, а затем заносить данные, что предотвратит ошибки, возникающие при попытке внести данные, нарушающие ограничения целостности в базу данных и связанные с их идентификацией.
3.4 Организация запросов к базе данных средствами языка SQL.
Формирование запросов - основная операция языка SQL, называемая отображением. Синтаксически это блок - SELECT-FROM-WHERE.
Операция отображения выполняется в следующей последовательности: сначала выполняется выбор горизонтального подмножества данных, соответствующих предикату выборки (соответствует операции реляционной алгебры - селекция), затем - вертикального подмножества данных (соответствует операции реляционной алгебры - проекция).
Формат команды выборки из одной таблицы:
SELECT [DISTINCT|ALL] < целевой список > FROM < имя таблицы>, WHERE < предикат >,
где целевой список – список имен столбцов и/или выражений над столбцами, элементы списка указываются через запятую (порядок элементов данных в целевом списке определяет порядок выборки данных);
Имя таблицы – имя тaблицы, из которой выбираются данные;
Предикат - условие выборки.
Условие выборки может включать следующие операторы:
1) Арифметические (=, !=, > ,<, >=, <=);
2) Логичские (AND, OR, NOT);
Порядок выполнения операторов задается скобками.
Альтернативой DISTINCT является ключевое слово ALL. Оно включает в состав отобранного множества строк все повторения.
Ниже приведены правила и примеры использования в пердикате специальных операторов сравнения: IN, BETWEEN, LIKE, IS NULL.
Оператор IN полностью определяет множество, которому данное значение может принадлежать или не принадлежать.
Оператор BETWEEN задает интервал принадлежности значения столбца заданным границам.
Оператор LIKE используется для поиска подстрок поэтому он применим только к столбцам с символьными данными (типа CHAR или VARCHAR). С этим оператором могут использоваться шаблоны. Оператор LIKE часто используется при поиске имени или названия, полное написание которого неизвестно.
Оператор IS NULL используется для поиска в таблице записей со значениями в заданном столбце NULL.
Функции агрегирования группируют значения столбца таблицы и возвращают значение вычисленной функции. Ниже приведен список таких функций.
1) COUNT функция подсчета количества строк или значений столбца, выбранного запросом, не являющихся пустыми (NULL).
Функция имеет следующий синтаксис:
COUNT ([DISTINCT | ALL] < выражение >)
При выполнении подсчета различных значений в столбце необходимо использовать слово DISTINCT.
Особый вариант использования функции COUNT (*) возвращает число строк в таблице, включая дубликаты и атрибуты с неопределенными значениями.
SUM - функция вычисления арифметической суммы значений выбранного столбца (для числовых выражений).
Функция имеет следующий синтаксис:
SUM ([DISTINCT | ALL] < выражение >)
2) AVG - функция вычисления среднего значения в выбранном столбце таблицы (для числовых выражений).
Функция имеет следующий синтаксис:
AVG ([DISTINCT | ALL] <выражение>)
3) MAX - функция выбора наибольшего значения из всех значений выбранного столбца таблицы;
Функция имеет следующий синтаксис:
MAX ([DISTINCT | ALL] < выражение >)
Допускаются аргументы типа числовой, символьный и дата.
4) MIN - функция выбора наименьшего значения из всех значений выбранного столбца таблицы;
Функция имеет следующий синтаксис:
MIN ([DISTINCT | ALL] < выражение >)
Допускаются аргументы типа числовой, символьный и дата.
Организация группировки данных для их совместной обработки выполняется с помощью ключевых слов GROUP BY. Совместная обработка данных обычно сводится к вычислению некоторой функции: суммы, среднего значения, числа элементов множества отобранных значений и т. п. Использование ключевых слов GROUP BY приводит к тому, что оператор SELECT выдает по одной строке для каждой группы записей, формируемых на основе одинаковых значений или выражений в столбцах.
Синтаксис конструкции группировки строк:
GROUP BY < выражение >, [< выражение >] ...[HAVING <условие>]
Ключевое слово НАVING используется для уточнения, какие группы из GROUP BY будут включаться в окончательный результат. Предложения, содержащие ключевые слова GROUP BY и НАVING, обрабатываются следующим образом:
Условие, заданное ключевым словом HAVING, относится к сформированной условием GROUP BY группе, а не к конкретным значениям атрибута.
Для выполнения сортировки результатов запроса по возрастанию или убыванию используются ключевые слова ORDER ВY.
Сортировка задается следующей синтаксической конструкцией:
ORDER BY < выражение > | < положение > [ASC | DESC] [,...]
Параметр < выражение > базируется на одном или нескольких столбцах, перечисленных после ключевого слова SELECT через запятую. Строки с одинаковыми значениями по первому выражению упорядочиваются по второму выражению (если оно определено) и так далее.
Параметр < положение > задает число, идентифицирующее позицию столбца в перечислении после ключевого слова SELECT, то есть вместо указания имен столбцов, можно указать номер позиции столбца в описке SELECT.
UNION ALL – формальное объединение результатов всех исходных запросов с сохранением дублированных строк.
Соединение (JOIN) является одной из наиболее часто используемых и наиболее мощных операций реляционной алгебры и является противоположностью другой часто используемой операции – проецирования (PROJECT). С помощью операции JOIN устанавливаются связи между отношениями.
Формат команды выборки данных из нескольких связанных таблиц имеет вид:
SELECT <имя таблицы. имя столбца>,…,<имя таблицы. имя столбца> FROM <список имен таблиц> [WHERE <предикат>]
После слова SELECT указывают имена столбцов таблиц с указанием префиксов имен таблиц, имена самих таблиц перечисляются после слова FROM, имена столбцов таблиц определяются друг от друга запятыми. Операция соединения, с операндами представленными одной таблицей.
Соединение таблицы с ее копией означает возможность комбинировать любую строку таблицы с любой другой строкой этой же таблицы. Каждая такая комбинация оценивается в терминах предиката, как и в случае соединения двух разных таблиц. Это позволяет конструировать различные связи между данными одной таблицы.
SQL позволяет выполнять запросы с вложенными подзапросами. Количество вложений одного запроса в другой практически не ограничено. Обычно внутренний запрос генерирует значения, которые проверяются на предмет истинности предиката (это относится ко всем запросам за исключением коррелированных запросов). Выполнение запроса осуществляется в следующей последовательности: выполняется внутренний запрос, его результат запоминается, затем выполняется основной запрос.
В подзапросе нельзя выполнять поиск по нескольким столбцам. Вариант “SELECT *” в подзапросе возможен только в случае применения оператора EXIST.
Подзапросы могут основываться на операторах отношений (=, <>, <, >, <=, >=) или операторе IN(или IS IN).
Операторы отношений применяются, когда есть уверенность в том, что результатом выполнения подзапроса является единственная запись.
Для формулирования подзапросов, в результате выполнения которых получается любое количество строк, применяется оператор IN. Он определяет множество значений, которые тестируются на совпадение с другими значениями для определения истинности предиката.
Любая коммерческая СУБД включает оптимизатор запросов. Оптимизатор преобразует версию запроса с соединением в версию с подзапросом. Поэтому при написании подзапросов следует использовать заведомо более эффективный вариант.
EXIST – оператор существования/отсутствия использует подзапрос в качестве аргумента и принимает значение “истина”, если подзапрос генерирует выходные данные, в противном случае генерирует “ложь”. Его можно применять в предикате отдельно или комбинировать с булевыми операторами.
Оператор NOT EXISTS противоположен по назначению оператору EXISTS и принимает значение “истина”, если результирующее множество пусто.
Операторы ANY, SOME, ALL также как и оператор EXISTS используют в качестве аргументов подзапросы.
Операторы ANY и SOME взаимозаменяемы – выполняются одинаково.
Оператор ALL возвращает значение “истина”, если каждое значение, выбранное при выполнении подзапроса, удовлетворяет условию внешнего запроса.
3.5 Создание запросов к базе данных «Деканат».
Описание запросов актуальных для данной информационной системы.
ЗадолжПредм: выводит список должников по предмету, который задается с клавиатуры.
SELECT Предмет.название, Студент.ФИО, Студент.специальность, Студент.год_поступления, Студент.номер_группы, Препод.ФИО
FROM Препод INNER JOIN (Предмет INNER JOIN (Студент INNER JOIN СдачаЭкз ON Студент.№зачетки = СдачаЭкз.№зачетки) ON Предмет.№предм = СдачаЭкз.№предм) ON Препод.№препод = Предмет.№препод
WHERE (((Предмет.название)=[Введите название предмета]) AND ((СдачаЭкз.оценка)<3));
ЗадолжГр: выводит список должников в группе, которая задается с клавиатуры.
SELECT Студент.специальность, Студент.год_поступления, Студент.номер_группы, Студент.ФИО, Предмет.название, Препод.ФИО
FROM Препод INNER JOIN (Предмет INNER JOIN (Студент INNER JOIN СдачаЭкз ON Студент.№зачетки = СдачаЭкз.№зачетки) ON Предмет.№предм = СдачаЭкз.№предм) ON Препод.№препод = Предмет.№препод
WHERE (((Студент.специальность)=[Введите cпециальность]) AND ((Студент.год_поступления)=[Введите год поступл]) AND ((Студент.номер_группы)=[Введите №группы]) AND ((СдачаЭкз.оценка)<3));
ЗадолжПрепод: выводит список студентов не сдавших экзамен у указаного преподавателя.
SELECT Препод.должн, Препод.ФИО, Предмет.название, Студент.ФИО, Студент.специальность, Студент.год_поступления, Студент.номер_группы
FROM Студент INNER JOIN (Препод INNER JOIN (Предмет INNER JOIN СдачаЭкз ON Предмет.№предм = СдачаЭкз.№предм) ON Препод.№препод = Предмет.№препод) ON Студент.№зачетки = СдачаЭкз.№зачетки
WHERE (((Препод.ФИО)=[Введите ФИО препод]) AND ((СдачаЭкз.оценка)<3));
МедОсмотр: мед.осмотр.
SELECT Студент.ФИО, Студент.специальность, Студент.год_поступления, Студент.номер_группы
FROM Студент
WHERE (((Студент.мед_осмотр)=No));
Флюрография: выводит список студентов не сдавших флюрографию.
SELECT Студент.ФИО, Студент.специальность, Студент.год_поступления, Студент.номер_группы
FROM Студент
WHERE (((Студент.флюрогр)=No));
СрБалГр: выводит средний балл указанной группы.
SELECT Студент.специальность, Студент.год_поступления, Студент.номер_группы, Avg(СдачаЭкз.оценка) AS [Avg-оценка]
FROM Студент INNER JOIN СдачаЭкз ON Студент.№зачетки = СдачаЭкз.№зачетки
GROUP BY Студент.специальность, Студент.год_поступления, Студент.номер_группы
HAVING (((Студент.специальность)=[Введите специальность]) AND ((Студент.год_поступления)=[Введите год поступления]) AND ((Студент.номер_группы)=[номер группы]));
СрБалСтуд: выводит средний балл указанного студента.
SELECT [Студент].[ФИО], [Студент].[специальность], [Студент].[год_поступления], [Студент].[номер_группы], Avg([СдачаЭкз].[оценка]) AS [Avg-оценка]
FROM Студент INNER JOIN СдачаЭкз ON [Студент].[№зачетки]=[СдачаЭкз].[№зачетки]
GROUP BY [Студент].[ФИО], [Студент].[специальность], [Студент].[год_поступления], [Студент].[номер_группы]
HAVING (((Студент.ФИО)=[Введите ФИО студента]));
СдалиНЕ: выводит список студентов не сдавших сессию.
SELECT DISTINCT [Студент].[ФИО]
FROM Студент INNER JOIN СдачаЭкз ON [Студент].[№зачетки]=[СдачаЭкз].[№зачетки]
WHERE (((Студент.ФИО) Not In (SELECT Студент.ФИО FROM Студент INNER JOIN СдачаЭкз ON Студент.№зачетки = СдачаЭкз.№зачетки WHERE (((СдачаЭкз.оценка)<3)))));
ЗАКЛЮЧЕНИЕ
В ходе курсовой работы была разработана автоматизированная информационно-справочная система хранения и обработки информации о студентах, преподавателях, предметах, которая способствует быстрому поиску необходимых данных при минимальных затратах времени, а также программная реализация системы, в основе которой лежит проектирование предметной области и логической схемы БД, являющейся информационным ресурсом разрабатываемой системы.
Ø информационно-справочная система реализует следующие функции:
Ø ввод данных в БД;
Ø поддержание целостности и безопасности данных в БД при их хранении;
Ø поддержание семантического смысла данных.
С помощью данной БД можно получить следующие, актуальные в данной работе сведения: о студентах не сдавших сесию, средний бал по предмету в группе, средний бал каждого студента, сдана ли флюрография и пройден ли мед.осмотр, также можно получить ведомости задолженностей по группе, предмету, преподавателю.
Разработанная система позволяет решать задачи поиска информации в БД по запросу пользователя и выдавать информацию в удобном для работы и наглядном для непрофессионала виде.
Современные базы данных являются основой многочисленных информационных систем. Информация, накопленная в них, является чрезвычайно ценным материалом, и в настоящий момент широко распространяютсяметоды обработки баз данных с точки зрения извлечения из них дополнительных знаний, методов, которые связаны с обобщением и различными дополнительными способами обработки данных.
СПИСОК ЛИТЕРАТУРЫ
1. Дейт К. Введение в системы баз данных.- 6-е изд.-К:Диалектика, 1998.-784с.
2. Бойко В.В., Савинков В.М. Проектирование баз данных и информационных систем. - М.: Финансы и статистика, 1989. - 351 с
3. Ульман Дж.Основы систем баз данх.М.:Финасы и статистика,1983.-334с.
4. Карпова Т. Базы Данных. С.-П., М.,Х.,М.,2001, - 304с.
5. Боуман Дж.,Эмерсон С.,Дарновски М.Практичесское руководство по SQL.-К:Диалектика,1998-565с.
6.Дрибас В.П. Реляционные модели данных. – Минск: Изд-во БГУ, 1982. – 192с.
7.Буслік М.М.Оптимальні зображення реляційних структур даних.-К:ІСДО,1993ю-84с.
8. Робинсон С. Access 2000 Современное средство для управления и разработки баз данных. – С.-П. Питер, 2001. – 512с.
ПРИЛОЖЕНИЕ А
Для удобной работы с базой данных была создана основная кнопочная форма из которой можно открыть все другие формы и просмотреть результаты запросов, а также таблицы и отчеты.
Главная кнопочная форма.
Дочернии кнопочные формы.
ПРИЛОЖЕНИЕ Б
Были созданы также формы для ввода и изменения текущих данных.
ПРИЛОЖЕНИЕ В
Схема данных:
