Рейтинг студента

Датологическая.dwg

Строительство торгового комплекса по адресу:
БР100.30.15 ГОСТ 6665-91
плотный асфальтобетон
Фрaкционный щебень фракции 20-40мм по
пропитанный битумомом на глубину
фракции 40-70 по ГОСТ 25607-97
TB_Plans (учебныепланы)
TB_VIDNAGR (вид нагрузки)
TB_TYPNAGR (тип нагрузки)
TB_SPEC (специальности)
TB_FORM (форма обучения)
TB_DISC (дисциплины)
TB_KAFEDRY (кафедры)
TB_Intermark (рейтинг)
Ссылка на код плана.
Схема даталогической модели

БД_куск.doc

Пояснительная записка содержит подробное описание хода разработки базы данных и программных средств для её обслуживания и обработки по теме “Рейтинг студентов”. Пояснительная записка состоит из 9 основных разделов которые занимают 27 листа печатного текста. К основным разделам относятся: анализ предметной области анализ информационных потребностей пользователя описание основных объектов предметной области разработка концептуальной (инфологической) модели предметной области нормализация базы данных выбор и обоснование систем управления баз данных для реализации базы данных разработка даталогической модели базы данных разработка структуры диалога ограничения целостности в базах данных и разработка методов их поддержания.
Расчетно-пояснительная записка содержит 6 таблицы и 4 рисунка.
Министерство образования и науки Украины
Восточноукраинский национальный университет им. В. Даля
название и номер специальности
Задание на курсовой проект
название академической группы
Наименование темы курсового проекта
Дата получения задания студентом
Термин сдачи студентом законченного проекта
Начальные данные для работы:
Состав вопросов которые должны быть обозначены в основной части пояснительной записки:
Список графического материала:
Календарный план выполнения работы:
Отметка про выполнение
АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ (ПО)2
АНАЛИЗ ИНФОРМАЦИОННЫХ ПОТРЕБНОСТЕЙ ПОЛЬЗОВАТЕЛЕЙ5
ОПИСАНИЕ ОСНОВНЫХ ОБЪЕКТОВ ПО6
РАЗРАБОТКА КОНЦЕПТУАЛЬНОЙ (ИНФОЛОГИЧЕСКОЙ) МОДЕЛИ ПО9
1. Уточнение понятия инфологической модели9
2. Требования предъявляемые к инфологической модели10
3. Компоненты инфологической модели11
НОРМАЛИЗАЦИЯ БАЗЫ ДАННЫХ14
1. Первая нормальная форма14
2. Вторая нормальная форма15
3. Третья нормальная форма15
4. Четвертая нормальная форма15
5. Пятая нормальная форма16
ВЫБОР И ОБОСНОВАНИЕ СУБД ДЛЯ РЕАЛИЗАЦИИ БАЗЫ ДАННЫХ17
РАЗРАБОТКА ДАТАЛОГИЧЕСКОЙ МОДЕЛИ БАЗЫ ДАННЫХ21
РАЗРАБОТКА СТРУКТУРЫ ДИАЛОГА23
1. Пользовательский интерфейс23
ОГРАНИЧЕНИЯ ЦЕЛОСТНОСТИ В БД И РАЗРАБОТКА МЕТОДОВ ИХ ПОДДЕРЖАНИЯ31
1 Первичные и внешние ключи31
2. Ограничения целостности33
В настоящее время большинство средних и крупных государственных и коммерческих организаций постепенно отказываются от использования только персональных компьютеров и начинают всерьёз задумываться о создании действительно открытых и распределённых информационных систем на мощной компьютерной платформе. Переломным в этом смысле стал 1994 год в течение которого в нашей стране можно было наблюдать взрыв интереса к многопользовательским СУБД. А предпосылками создания БД являются объекты реального мира которые находятся в постоянном взаимодействии. Это требует наличия модели предметного мира в котором отдельные части связаны между собой.
Преимущества создания и использования БД на сегодняшний день такие: наличие единого целостного описания определенной части реального мира обеспечивающий возможность обращаться к информации не только за решением определенных задач но и для поисков ответов на непредвиденный вопрос; использование БД дает возможность сократить объем документооборота; повышение качества разработки так как вопросами программирования занимаются только ограниченное число профессиональных программистов; наличие развитых средств интерфейса позволяет работать неподготовленным пользователям; централизованное управление данными освобождает от этих функций всех кроме администратора; реализован принцип независимости программ от данных.
Однако существует ряд требований для создания БД. Основными из них являются актуальность информации дружелюбный интерфейс и малое время на усвоение системы независимость программы данных возможность работы пользователя в разных категориях.
Сегодня видимо нет серьёзных факторов сдерживающих распространение таких систем если не считать скромные финансовые возможности многих организаций и слабую информированность пользователей преимущественно в технологической сфере.
Однако сам по себе переход к многопользовательским системам управления базами данных (СУБД) – это не просто освоение новой системы. Он представляет собой качественный технологический скачок требующий не только чисто технических но и административных кадровых финансовых и других решений.
Важнейшая задача компьютерных систем – хранение и обработка данных. Для её решения были предприняты усилия которые привели к появлению в конце 60-х начале 70-х годов специализированного программного обеспечения – систем управления базами данных (Data GBase Management Systems – DBMS ) которые позволяют структурировать систематизировать и организовать данные для их компьютерного хранения и обработки.
АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ (ПО)
Предметной областью создаваемой базы данных является расчет рейтинга для студента. Рейтинг студента среди его сокурсников всегда имел важное значение интересовал каждого студента следовательно данный вопрос будет всегда актуальным. Конструируя структуру Базы Данных выделим ее основные элементы. Сайт содержит справочники в которых расположена информация о кафедре дисциплинах форме обучения и т.д. взаимодействующие с БД здесь пользователь может ознакомиться с интересующей его информацией. Пользователь выбирает необходимые данные и может просмотреть свой рейтинг среди студентов.
Разработанное приложение должно решать следующие задачи:
- хранить базовую информацию о студентах.
- хранить информацию о контракте каждого студента.
- выполнять расчет рейтинга для каждого студента.
- поддерживать целостность базы данных на уровне клиента.
Могут быть выделены следующие информационные потребности:
- Информация о кафедрах.
- Информация о дисциплинах.
- Информация о форме обучения.
- Информация о типах нагрузки.
- Информация о специальностях.
АНАЛИЗ ИНФОРМАЦИОННЫХ ПОТРЕБНОСТЕЙ ПОЛЬЗОВАТЕЛЕЙ
Информационные потребности пользователей выражаются в запросах которые они могут предъявлять к созданной базе данных.
Различают запросы регламентированные (предусмотренные) и нерегламентированные. Регламентированные запросы – это запросы пользователей которые учитываются при проектировании базы данных.
При проектировании нашей базы данных можно выделить следующие регламентированные запросы:
- информация о кафедрах: название кафедры;
- информация о дисциплинах: название дисциплин названия кафедр которые читают данные дисциплины;
- информация о форме обучения: название формы обучения;
- информация о специальностях: названия специальностей.;
- информация о типе нагрузок: название нагрузок;
- информация о виде нагрузок: название нагрузок.
ОПИСАНИЕ ОСНОВНЫХ ОБЪЕКТОВ ПО
В предметной области в процессе ее исследования и анализа выделяют классы объектов. Классом объектов называют совокупность объектов обладающих одинаковым набором свойств.
Объекты могут быть реальными а могут быть и абстрактными. При отображении в информационной системе каждый объект представляется своим идентификатором который отличает один объект класса от другого а каждый класс объектов представляется именем этого класса. Так для объектов класса «Студенты» идентификатором каждого объекта будет «U» (код студента). Естественно для того чтобы отличать один объект класса от другого идентификатор должен быть уникальным.
Каждый объект обладает определенным набором свойств. Для объектов одного класса набор этих свойств одинаков а их значения конечно же могут различаться. Отбор объектов предметной области производится на основе анализа информационных потребностей. Ниже приведены таблицы описания объектов.
Таблица 1. Список объектов предметной области.
Наименование объекта
Информация о кафедрах
Информация о типах нагрузки
Информация о видах нагрузки
Информация о форме обучения
Информация о группах
Информация о студентах и преподавателях
Сборная информация планам дисциплинам кафедрам
Информация о дисциплинах
Информация об учебных планах
Сборная информация об успеваемости студентов
На основе анализа информационных запросов были выявлены связи между объектами предметной области. Для выявленных связей этих связей была заполнена нижеприведенная таблица.
Таблица 2. Список связей ПО
Объекты участвующие в связи
Кафедра и учебный план
Тип нагрузки и вид нагрузки
Кафедра и дисциплины
Группы и специальность
Группы и форма обучения
Специальность и план
Теперь проведя анализ ПО и выявив информационные потребности пользователя можно приступить к созданию инфологической модели нашей базы данных.
РАЗРАБОТКА КОНЦЕПТУАЛЬНОЙ (ИНФОЛОГИЧЕСКОЙ) МОДЕЛИ ПО
1. Уточнение понятия инфологической модели
В базе данных отображается какая-то часть реального мира. Естественно что полнота ее описания будет зависеть от целей создаваемой информационной системы.
Для того чтобы база данных адекватно отражала предметную область проектировщик базы данных должен хорошо представлять себе все нюансы присущие данной предметной области (ПО) и уметь отобразить их в базе данных. Поэтому прежде чем начинать проектирование базы данных было тщательно изучено функционирование предметной области для отображения которой создавалась БД. Следует отметить что предметная область должна быть предварительно описана. Для этого в принципе может использоваться и естественный язык но его применение имеет много недостатков основными из них являются громоздкость описания и неоднозначность его трактовки. Поэтому обычно для этих целей используют искусственные формализованные языковые средства. В связи с этим под инфологической моделью (ИЛМ) понимают описание предметной области выполненное с использованием специальных языковых средств не зависящих от используемых в дальнейшем программных средств.
Инфологическая модель должна строиться вне зависимости от того будем ли мы в дальнейшем использовать какую-либо СУБД или пользоваться другими программными средствами для реализации своей информационной системы.
2. Требования предъявляемые к инфологической модели
Основным требованием к ИЛМ вытекающим из ее назначения является требование адекватного отображения предметной области. В связи с этим язык для представления ИЛМ должен обладать достаточными выразительными возможностями для отображения явлений имеющих место в предметной области. ИЛМ должна быть непротиворечивой. Она является единым интегрированным описанием предметной области и отражает взгляды и потребности всех пользователей системы. Не должна допускаться неоднозначная трактовка модели.
Несмотря на то что реальный мир отображаемый в ИЛМ является по своей природе бесконечным инфологическая модель является конечной что обеспечивается четким ограничением предметной области. Тем не менее в ИЛМ по разным причинам часто приходится вводить новые объекты. ИЛМ должна в связи с этим обладать свойством легкой расширяемости обеспечивающим ввод новых данных без изменения ранее определенных. То же самое можно сказать и об удалении данных. В связи с большой размерностью реальных инфологических
моделей должна обеспечиваться возможность композиции и декомпозиции модели.
Желательно чтобы язык спецификации ИЛМ был одинаково применим как при ручном так и при автоматизированном проектировании информационных систем. Последнее предъявляет дополнительные требования к нему а именно он должен: быть вычисляемым т. е. восприниматься и обрабатываться ЭВМ; использовать «дружелюбные» пользователю интерфейсы в частности графические; быть не зависимым от оборудования и других ресурсов которые подвержены частым изменениям; использовать средства тестирования ИЛМ а также иметь аппарат для указания того что спецификация завершена и по ней может быть выполнена генерация структур баз данных.
При автоматизированном проектировании все изменения внесенные в ИЛМ должны быть автоматически отражены в связанных с модифицируемым элементом компонентах банка данных.
3. Компоненты инфологической модели
Инфологическая модель должна легко восприниматься разными категориями пользователей. Инфологическая модель является средством коммуникации разнообразных коллективов как конечных пользователей так и разработчиков. Кроме того она является ядром системы проектирования. ИЛМ содержит необходимую и достаточную информацию для дальнейшего проектирования автоматизированной системы обработки информации. Информация из ИЛМ корреспондирует со словарной системой и другими компонентами банка данных.
Описание предметной области всегда представлено в какой-то знаковой системе. Поэтому кроме отношений присущих предметной области возникают еще и отношения обусловленные особенностями отображения ПО в языковой среде. Поэтому при построении ИЛМ должны учитываться такие лингвистические категории как синонимия омонимия изоморфизм и др.
Кроме того в инфологической модели должны быть отражены и алгоритмические зависимости между показателями. Обычно для этих целей используются графы взаимосвязи показателей отражающие какие показатели служат исходными для вычисления других (рис. 5.3.1.).
Рис. 5. 3. 1. Граф взаимосвязи показателей
Расчетные формулы а также алгоритмы вычислений также в каком-то виде должны быть представлены в ИЛМ.
Следующим компонентом инфологической модели является описание информационных потребностей пользователей. Для этих целей используются специальные языковые средства. Они должны отражать тип запроса объемно-частотные характеристики режим использования данных и т. п.
Тип связи характеризует количество экземпляров объектов каждого класса участвующих в связи. Различают четыре типа связи: «один к одному» (1:1) «один ко многим» (1:М) «многие к одному» (М:1) и «многие ко многим» (М:М). В связи типа 1:1 каждому экземпляру объектов одного класса соответствует строго один экземпляр объектов другого класса. Связь типа 1:М отображает отношение когда один экземпляр объектов одного класса связан с несколькими экземплярами объектов другого класса. Обратной по отношению к связи типа 1:М является связь типа М:1. Для того чтобы облегчить распознавание связей этих двух типов следует учитывать направление связи при этом тип связи определяется однозначно. Наиболее сложным типом связи является связь типа М:М. В связи этого типа любой экземпляр объектов одного типа может быть связан с несколькими экземплярами объектов другого типа. Это справедливо и по отношению к экземплярам объектов другого типа.
Класс принадлежности определяет обязательность вхождения каждого экземпляра объектов в связь. Различают обязательный и необязательный класс принадлежности. В первом случае каждый экземпляр класса объектов обязательно участвует в связи. Необязательный класс принадлежности показывает что допускаются экземпляры объектов которые не участвующие в связи.
Направление связи определяет путь при выполнении навигационных операций в базе данных. В настоящее время в литературе посвященной проблемам разработки ИЛМ не существует устоявшегося общепринятого подхода к проблеме использования направления связи в ИЛМ. В курсовом проекте для указания направления связи использовалась стрелка. Использование связей с направлениями облегчает построение ИЛМ упрощает планирование навигационных операций и акцентирует внимание разработчика на методах генерации ответов на предусмотренные запросы. Кроме того направление связи позволяет однозначно определить тип связи. С учетом направления между двумя классами объектов может существовать более одной связи.
НОРМАЛИЗАЦИЯ БАЗЫ ДАННЫХ
Вообще нормализацией называется процесс приведения структуры данных к реляционной форме. Основной результат нормализации — удаление из структуры таблиц избыточных элементов. Нередко после выполнения нормализации к структуре базы данных добавляется одна или несколько таблиц.
Хорошо нормализованная база данных обеспечивает разработчику очень широкие возможности по изменению механизмов обработки данных создаваемого приложения. Поэтому проводить нормализацию рекомендуется как можно раньше и обязательно перед началом разработки приложения.
Нормализация включает в себя пять этапов или форм причем каждая последующая форма основана на предыдущей. На практике используются только три первые формы нормализации а четвертая и пятая являются слишком специальными и в большинстве реальных проектов их можно не применять.
Формы нормализации не следует воспринимать как обязательные к исполнению жесткие правила. В ряде случаев для отдельных таблиц некоторыми формами можно пренебречь в интересах упрощения структуры данных или для ускорения процесса обработки больших объемов данных.
1. Первая нормальная форма
Каждое поле таблицы приведенной к первой нормальной форме должно содержать неразделимую информацию и не должно содержать повторяющиеся группы.
Поле считается неделимым если оно содержит только один элемент данных. Например поле «Адрес» в общем случае может содержать полный адрес включая улицу дом корпус квартиру. Значит такое поле содержитпринципиально разделяемую информацию. Поэтому данное поле необходимо разбить на несколько. Несложно например представить вариант когда потребуется иметь информацию о улицах отдельно.
Повторяющаяся группа — это поля которые совпадают по всем параметрам (кроме имени) и предназначены для хранения значений одного атрибута объекта.
Повторяющиеся группы полей значительно затрудняют обработку данных так как требуют дополнительного анализа данных внутри группы. Кроме этого они нарушают принципы объектного подхода при формировании структуры данных.
2. Вторая нормальная форма
Во второй нормальной форме все поля записи должны зависеть от первичного ключа или от каждого поля первичного ключа если ключ составной. Это означает что между значением первичного ключа и каждым полем должно существовать однозначное соответствие.
3. Третья нормальная форма
Третья нормальная форма требует полной зависимости полей от первичного ключа и полной независимости не ключевых полей друг от друга.
Например в таблице «Состав» наряду с уникальным номером бригады «Brigada» можно было хранить и ее название. Это существенно облегчило бы сортировку данных по работникам но потребовало бы введения специальной обработки данных — ведь вместе с изменением уникального номера бригады необходимо менять и ее название.
4. Четвертая нормальная форма
Четвертая нормальная форма запрещает хранить независимые элементы в одной таблице когда между этими элементами существуют отношения многие ко многим. Раз это отношение существует то поля перестают быть независимыми и нарушают требования третьей нормальной формы.
5. Пятая нормальная форма
Пятая нормальная форма требует сохранения всех возможных операций над данными по окончании нормализации. Эта форма страхует от возможной потери данных например от потери отдельных столбцов или разрыва связей между элементами.
ВЫБОР И ОБОСНОВАНИЕ СУБД ДЛЯ РЕАЛИЗАЦИИ БАЗЫ ДАННЫХ
Для создания данного курсового проекта использовала БД Interbase.
Понятие "Система Управления Базами Данных" (СУБД) она же DBMS (DataBase Managment System) может означать по большому счету все что угодно. В самом общем случае это собственно база данных которая предполагает какой либо метод сохранения информации на диске и возможности доступа и манипуляции с нею и набор программных продуктов предоставляющий пользователю все допустимые в базе средства работы с данными. Набор программных средств манипуляции данными СУБД удовлетворяет свойствам полноты (консистентности). Коммерческие варианты СУБД стремятся быть еще и замкнутыми т.е. самодостаточными не требующими и не поддающимися расширению.
Очень многие СУБД разделяют свою работу на два уровня по системе "Клиент-сервер". Разделение функций выполняется автоматически системой.
Итак двухуровневая система "Клиент-сервер" это:
клиент - Программа обработки она же пользовательская она же прикладная программа. Занимается обычно интерфейсом с пользователем а всю фактическую работу с базой данных возлагает на плечи БД-сервера;
сервер - базис (database engine) он же ядро базы данных. Отдельная программа выполняемая как отдельный процесс. Передает выбранную из базы информацию по межпроцессному каналу клиенту. Именно он и только он фактически работает с данными занимается их размещением на диске.
В первый момент может возникнуть вопрос а зачем такие сложности? Вот несколько соображений в пользу такого подхода. Представим что мы работаем в сети наша программа обработки идет на одном компьютере а сама база данных хранится на другом. Тут разделение выглядит совершенно естественным: клиент - наша программа (точнее та ее часть которая отвечает за интерфейс с нами) гонит по сети запросы на обработку самих данных на другой компьютер а там БД-сервер их считывает выполняет требуемое и по сети гонит ответы нам. При этом по сети передается только полезная информация.
Другое соображение: постоянно идет работа по совершенствованию самого метода хранения и обработки информации и если его реализация (т.е. БД-сервер) сменилась то нам не потребуется перелопачивать и перекомпилировать с новыми библиотеками все разработанные
программы а достаточно будет инсталлировать новый БД-сервер взамен старого и перевести наши базы данных в формат нового сервера (применив для этого прилагаемую к нему утилиту). Естественно все это можно проделать если новый сервер придерживается тех же правил обмена между ним и пользовательской программой что и старый что впрочем наверняка имеет место.
Для работы с базами данных используются специальные языки в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД т.е. той структуры БД какой она представляется пользователям. DML содержал набор операторов манипулирования данными т.е. операторов позволяющих заносить данные в БД удалять модифицировать или выбирать существующие данные.
В современных СУБД обычно поддерживается единый интегрированный язык содержащий все необходимые средства для работы с БД начиная от ее создания и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language).
Однако следует отметить что SQL – это не язык программирования в обычном понимании а это часть серверной базы данных.
SQL позволяет управлять данными сервера обеспечивая ряд функциональных возможностей.
Прежде всего язык SQL сочетает средства SDL и DML т.е. позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД - именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.
Язык SQL содержит специальные средства определения ограничений целостности БД. Опять же ограничения целостности хранятся в специальных таблицах-каталогах и обеспечение контроля целостности БД производится на языковом уровне т.е. при компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код.
Специальные операторы языка SQL позволяют определять так называемые представления БД фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей как любая базовая таблица хранимая в БД но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне.
Наконец авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Идея состоит в том что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь создавший таблицу БД обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах контроль полномочий поддерживается на языковом уровне.
Вышеизложенное позволяет понять почему именно SQL является основным средством разработки и управления данными в приложениях клиент-сервер.
Для создания приложения была выбрана среда разработки PHP версии 5.1.5
PHP (англ. PHP: Hypertext Preprocessor — «PHP: препроцессор гипертекста») — скриптовый язык программирования созданный для генерации HTML-страниц на веб-сервере и работы с базами данных. В настоящее время поддерживается подавляющим большинством хостеров.
Входит в XAMP — «стандартный» набор для создания веб-сайтов (Linux Apache MySQL PHP).
В области программирования для Сети PHP — один из популярнейших скриптовых языков (наряду с JSP Perl и языками используемыми в ASP.NET) благодаря своей простоте скорости выполнения богатой функциональности и распространению исходных кодов на основе лицензии PHP. PHP отличается наличием ядра и подключаемых модулей «расширений»: для работы с базами данных сокетами динамической графикой криптографическими библиотеками документами формата PDF и т. п. Любой желающий может разработать своё собственное расширение и подключить его. Существуют сотни расширений однако в стандартную поставку входит лишь несколько десятков хорошо зарекомендовавших себя. Интерпретатор PHP подключается к веб-серверу либо через модуль созданный специально для этого сервера (например для Apache или IIS) либо в качестве CGI-приложения.
РАЗРАБОТКА ДАТАЛОГИЧЕСКОЙ МОДЕЛИ БАЗЫ ДАННЫХ
Даталогическое проектирование - проектирование логической структуры базы данных в среде конкретной СУБД.
Для реляционной базы данных проектирование логической структуры заключается в том чтобы разбить всю информацию по файлам (или в терминах реляционной модели – по отношениям) а также определить состав полей (в терминах реляционной модели - атрибутов) для каждого из этих файлов.
Даталогическая модель может быть удобно представлена в виде таблицы специальной формы составляющейся для каждого отношения используемого в базе данных. Отношения в базе соответствуют классам объектов из инфологической модели. Кроме того отношения могут представлять некоторые связи предметной области.
В нижеприведенной таблице определяется какие поля будут содержать таблицы базы данных. При этом сразу устанавливаются типы данных для полей.
Тип данных определяется информацией которая будет храниться в поле. Необходимо рассчитать примерный максимальный и минимальный размер одного значения что также влияет на выбор типа данных. Еще один аспект который нужно учесть – особенности визуализации и редактирования данных.
Таблица TB_Kafedry(кафедры)
Таблица TB_Group(Группы)
Таблица TB_Plans(учебные планы)
Таблица TB_Spec(Специальности)
Связь главных таблиц с дочерними осуществляется через специальные поля содержащие порядковые номера соответствующих объектов в дочерних таблицах. В дальнейшем на основании этих полей определяются внешние ключи и задается ссылочная целостность.
РАЗРАБОТКА СТРУКТУРЫ ДИАЛОГА
1. Пользовательский интерфейс
Для того чтобы обеспечить пользователю минимальные усилия при работе с программой необходимо разработать такой интерфейс который как можно лучше соответствовал информационным потребностям пользователей и вместе с тем был бы как можно более удобным.
Перед созданием интерфейса приложения необходимо решить какой тип пользовательского интерфейса выбрать: многодокументный или однодокументный (соответственно MDI или SDI).
Многодокументный интерфейс хорош если большинство операций приложения выполняется в пределах рабочей области главного окна приложения и все дочерние окна предназначены для выполнения подобных операций или содержат однотипную информацию.
Однодокументный интерфейс применяется когда все дочерние окна выполняют разнородные функции слабо связаны между собой и их положение на экране относительно главного окна несущественно.
Основными операциями программы будут:
получение общей информации о рейтинге;
Главная страница приложения показана на рис.4
Рис 4. Главное окно приложения
Страничка выбора необходимых данных и расчета рейтинга на рис. 5
Рис. 5 Страничка расчета рейтинга
Для расчета рейтинга необходимо выбрать год специальность и ФИО студента которого интересует рейтинг. Ниже представлен скрип который позволяет нам выбрать имеющиеся данные из БД т.е. осуществляет работу с базой. ?PHP
DATABASE = "LOCALHOST:IRA";
PASSWORD = "MASTERKEY";
DB = IBASE_CONNECT(DATABASE USER PASSWORD);
EXTRACT(HTTP_POST_VARS);
EXTRACT(HTTP_GET_VARS);
REQUIRE_ONCE 'FUNCTIONS.PHP';
RESULT=IBASE_QUERY("SELECT DISTINCT Y FROM TABLE");
----------ВЫБИРАЕМ ГОД------------
OUT1='FORM METHOD=POST>';
OUT1.='SELECT NAME="YEAR" CLASS="TEXT">';
IF(I==YEAR) OUT1.='OPTION VALUE='.I.' SELECTED>'.I.'OPTION>'; ELSE
OUT1.='OPTION VALUE='.I.'>'.I.'OPTION>';
----------ВЫБИРАЕМ СПЕЦИАЛЬНОСТЬ------------
OUT2.='BR>SELECT NAME="SPEC" CLASS="TEXT">';
RESULT=IBASE_QUERY("SELECT DISTINCT U NAME FROM TB_SPEC");
WHILE (ROW = IBASE_FETCH_ROW(RESULT))
IF(ROW[0]==SPEC) OUT2.='OPTION VALUE='.ROW[0].' SELECTED>'.ROW[1].'OPTION>'; ELSE
OUT2.='OPTION VALUE='.ROW[0].'>'.ROW[1].'OPTION>';
----------ПРОВЕРЯЕМ НЕ ПУСТЫЕ ЛИ ЗНАЧЕНИЯ------------
IF(EMPTY(YEAR))YEAR=0;
IF(EMPTY(SPEC))SPEC=0;
----------ВЫПОЛНЯЕМ ЗАПРОС ПО КОТОРОМУ ОТБИРАЕМ ФИО------------
SQL_Q="SELECT TB_KADRY.U TB_KADRY.FAM ' ' TB_KADRY.NAME ' ' TB_KADRY.MIDNAME FIO
FROM TB_PLANS TB_KADRY TB_GROUP TB_SPEC
WHERE TB_SPEC.U=TB_PLANS.SPEC
AND TB_PLANS.SPEC=SPEC
AND TB_GROUP.ID_PLAN=TB_PLANS.U
AND TB_GROUP.U=TB_";
RESULT = IBASE_QUERY(SQL_Q) OR DIE(IBASE_ERRMSG());
----------ВЫБИРАЕМ ФИО------------
OUT3.='BR>SELECT NAME="FIO" CLASS="TEXT">';
IF(ROW[0]==FIO) OUT3.='OPTION VALUE='.ROW[0].' SELECTED>'.ROW[1].'OPTION>'; ELSE
OUT3.='OPTION VALUE='.ROW[0].'>'.ROW[1].'OPTION>';
------ВЫПОЛНЯЕМ ЗАПРОС ПО КОТОРОМУ ПОДСЧИТЫВАЕМ СУММУ И КОЛ-ВО ОЦЕНОК----
SQL_Q="SELECT SUM(TB_INTERMARK.MARK) COUNT(TB_INTERMARK.MARK) TB_KADRY.FAM' 'TB_KADRY.NAME' 'TB_KADRY.MIDNAME FIO
FROM TB_KADRY TB_INTERMARK
WHERE TB_INTERMARK.SH=FIO AND
TB_INTERMARK.SH=TB_KADRY.U AND
TB_INTERMARK.VN IN (591011)
ROW=IBASE_FETCH_ROW(RESULT);
------РАСЧИТЫВАЕМ РЙТИНГ----------
OUT.="H1>РЕЙТИНГ ДЛЯ СТУДЕНТА ".ROW[2]." - ".(ROUND((ROW[0]ROW[1])3))."H1>";
OUT.="H1>НЕТ РЕЗУЛЬТАТОВ ПО ДАННОМУ СТУДЕНТУH1>";
OUT.='BR>INPUT TYPE="HIDDEN" NAME="GO" VALUE="1">INPUT CLASS="TEXT" TYPE=SUBMIT VALUE="OK">FORM>';
FOR (I = 0 N = IBASE_NUM_FIELDS(RESULT); I N; I++)
COL_INFO = IBASE_FIELD_INFO(RESULT I);
FIELDS[] = GET_NAME(COL_INFO['NAME']);
Просмотр справочников:
Просмотр справочников осуществляет при помощи данного скрипта:
PASSWORD="MASTERKEY";
RESULT=IBASE_QUERY("SELECT TB_DISC.NAME TB_KAFEDRY.NAME FROM TB_DISC TB_KAFEDRY WHERE TB_DISC.KAF=TB_KAFEDRY.U");
OUT='TABLE>TR>TH>ИМЯTH>TH>КАФЕДРАTH>TR>';
WHILE (ROW = IBASE_FETCH_ROW(RESULT))
OUT.='TR>TD>'.ROW[0].'TD>TD>'.ROW[1].'TD>TR>';
В итоге можно сказать что сайт написан в едином стиле имеет систему навигации взаимодействуем с БД имеет удобный интерфейс.
ОГРАНИЧЕНИЯ ЦЕЛОСТНОСТИ В БД И РАЗРАБОТКА МЕТОДОВ ИХ ПОДДЕРЖАНИЯ
1 Первичные и внешние ключи
Ключ или возможный ключ – это минимальный набор атрибутов по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Каждая сущность обладает хотя бы одним возможным ключом. Один из них принимается за первичный ключ. При выборе первичного ключа следует отдавать предпочтение несоставным ключам или ключам составленным из минимального числа атрибутов. Нецелесообразно также использовать ключи с длинными текстовыми значениями (предпочтительнее использовать целочисленные атрибуты). Так для идентификации плательщика можно использовать уникальный номер расчетного счета. Плохо использовать в качестве ключа не номер тарифа а его название.
Не допускается чтобы первичный ключ стержневой сущности (любой атрибут участвующий в первичном ключе) принимал неопределенное значение. Иначе возникнет противоречивая ситуация: появится не обладающий индивидуальностью и следовательно не существующий экземпляр стержневой сущности. По тем же причинам необходимо обеспечить уникальность первичного ключа.
Теперь о внешних ключах:
Если сущность С связывает сущности А и В то она должна включать внешние ключи соответствующие первичным ключам сущностей А и В.
Если сущность В обозначает сущность А то она должна включать внешний ключ соответствующий первичному ключу сущности А.
Для обозначения любой из ассоциируемых сущностей (стержней характеристик обозначений или даже ассоциаций) используется новый обобщающий термин "Цель" или "Целевая сущность".
Таким образом при рассмотрении проблемы выбора способа представления ассоциаций и обозначений в базе данных основной вопрос на который следует получить ответ: "Каковы внешние ключи?". И далее для каждого внешнего ключа необходимо решить три вопроса:
Может ли данный внешний ключ принимать неопределенные значения (NULL-значения)? Иначе говоря может ли существовать некоторый экземпляр сущности данного типа для которого неизвестна целевая сущность указываемая внешним ключом?
В случае лицевых счетов это вероятно невозможно – лицевые счета которые принадлежат неизвестным плательщикам не имеют смысла. Но в случае с тарифами такая ситуация однако могла бы иметь смысл – вполне возможно что каким-либо тарифом в данный момент не пользуется вообще ни какой плательщик. Заметим что ответ на данный вопрос не зависит от прихоти проектировщика базы данных а определяется фактическим образом действий принятым в той части реального мира которая должна быть представлена в рассматриваемой базе данных. Подобные замечания имеют отношение и к вопросам обсуждаемым ниже.
Что должно случиться при попытке УДАЛЕНИЯ целевой сущности на которую ссылается внешний ключ? Например при удалении улицы на которой находится по крайней мере один плательщик. Существует три возможности:
- каскадируется - операция удаления "каскадируется" с тем чтобы удалить также этого плательщика;
- ограничивается т.е. улицы удаляются выборочно при выполнении определенных условий. Иначе операция удаления отвергается;
- устанавливается - для всех плательщиков расположенных на удаляемой улице внешний ключ устанавливается в неопределенное значение а затем эта улица удаляется. Такая возможность конечно неприменима если данный внешний ключ не должен содержать NULL-значений.
Что должно происходить при попытке ОБНОВЛЕНИЯ первичного ключа целевой сущности на которую ссылается некоторый внешний ключ? Например может быть предпринята попытка обновить номер такой улицы на которой находится по крайней мере один плательщик. В этом случае имеются те же три возможности как и при удалении.
Таким образом для каждого внешнего ключа в проекте проектировщик базы данных должен специфицировать не только поле или комбинацию полей составляющих этот внешний ключ и целевую таблицу которая идентифицируется этим ключом но также и ответы на указанные выше вопроса (три ограничения которые относятся к этому внешнему ключу).
Наконец о характеристиках – обозначающих сущностях существование которых зависит от типа обозначаемых сущностей. Обозначение представляется внешним ключом в таблице соответствующей этой характеристике. Но три рассмотренные выше ограничения на внешний
ключ для данного случая должны специфицироваться следующим образом:
NULL-значения не допустимы
УДАЛЕНИЕ ИЗ (цель) КАСКАДИРУЕТСЯ
ОБНОВЛЕНИЕ (первичный ключ цели) КАСКАДИРУЕТСЯ
Указанные спецификации представляют зависимость по существованию характеристических сущностей.
2. Ограничения целостности
Целостность (от англ. integrity – нетронутость неприкосновенность сохранность целостность) – понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например нельзя обнаружить что вводимое значение 5 (представляющее номер месяца мая) в действительности должно быть равно 3. С другой стороны значение 14 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить что номера месяцев должны принадлежать набору (123456789101112).
Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений (не путать с незаконными изменениями и разрушениями являющимися проблемой безопасности).
Выделяют три группы правил целостности:
- Целостность по сущностям.
- Целостность по ссылкам.
- Целостность определяемая пользователем.
Выше была рассмотрена мотивировка двух правил целостности общих для любых реляционных баз данных.
Не допускается чтобы какой-либо атрибут участвующий в первичном ключе принимал неопределенное значение.
Значение внешнего ключа должно либо:
- быть равным значению первичного ключа цели;
- быть полностью неопределенным т.е. каждое значение атрибута участвующего во внешнем
ключе должно быть неопределенным.
Для любой конкретной базы данных существует ряд дополнительных специфических правил которые относятся к ней одной и определяются разработчиком.
Результатом выполнения данного курсового проекта стало приобретение навыков разработки законченных программных комплексов для решения практических задач в области обработки данных с использованием современных СУБД (InterBase v5.2) а также закрепление и расширение знаний полученных при изучении теоретического материала по курсу «Базы данных».
В ходе разработки курсового проекта были разработаны инфологическая и даталогическая модели разрабатываемой базы данных создана необходимая база данных и впоследствии была разработана программа имеющая понятный пользователю интерфейс а также обеспечивающая удобный и простой доступ к созданной базе данных обслуживание и обработку разработанной базы данных.
Диго С. М. Проектирование и использование баз данных: Учебник. – М.: Финансы и статистика 1995. – 208 с.: ил.
С. М. Парижский Н. А. Литвиненко PHP. Теория и практика.
Софоненко «Базы данных» Ленинград 2005г.

Инфологическая.dwg

Строительство торгового комплекса по адресу:
БР100.30.15 ГОСТ 6665-91
плотный асфальтобетон
Фрaкционный щебень фракции 20-40мм по
пропитанный битумомом на глубину
фракции 40-70 по ГОСТ 25607-97
Количество часов по дисциплине
Направление обучения
Количество недель в семестре
Схема инфологической модели

Интерфейс.dwg

Строительство торгового комплекса по адресу:
БР100.30.15 ГОСТ 6665-91
плотный асфальтобетон
Фрaкционный щебень фракции 20-40мм по
пропитанный битумомом на глубину
фракции 40-70 по ГОСТ 25607-97
Интерфейс пользователя