Проектирование базы данных
Проектирование БД связанно с разрешением проблем представления данных
между конечными пользователями. Они продиктованы различными
потребностями и задачами лиц, которые используют эти данные.
Пользователи могут быть выделены в отдельные группы. Каждая из групп
воздействует на результаты проектирования в разных направлениях.
Необходимо собрать информацию о реальных и потенциальных приложениях, а
также о пользователях базы данных, чтобы устранить все противоречия ещё
на начальном этапе, так как многолетний мировой опыт использования
информационных систем, построенных на основе баз данных, показывает, что
недостатки проекта допущенные на этапе проектирования невозможно
устранить любыми ухищрениями в программах приложений.
Проектирование обычно поручается человеку (группе лиц) – администратору
базы данных (АБД). Им может быть как специально выделенный сотрудник,
так и будущий пользователь базы данных, достаточно хорошо знакомый с
машинной обработкой данных.
В основу проектирования БД должны быть положены представления конечных
пользователей конкретной организации — концептуальные требования к
системе. Именно конечный пользователь в своей работе принимает решения с
учетом получаемой в результате доступа к базе данных информации. От
оперативности и качества этой информации будет зависеть эффективность
работы организации. Данные, помещаемые в базу данных, также
предоставляет конечный пользователь. Кроме того, БД должна предоставлять
доступ к данным пользователям, которые практически не имеют или не хотят
иметь представления о физическом размещении в памяти данных и их
описаний, о механизмах поиска запрашиваемых данных или о поддержании баз
данных в актуальном состоянии.[15].
Прикладные программисты хотели бы иметь в одном месте (например, в одной
таблице) все данные, необходимые им для реализации запроса из прикладной
программы или с терминала.
АБД же заботятся об исключении возможных искажений хранимых данных при
вводе в базу данных новой информации и обновлении или удалении
существующей. Для этого они удаляют из базы данных дубликаты и
нежелательные функциональные связи между таблицами, разбивая базу данных
на множество маленьких таблиц.
Чтобы различать представления данных конечными пользователями,
программистами и АБД создаются разные уровни моделей данных. Их общая
структура представлена на рис. 14.
Основное различие между указанными выше тремя типами моделей данных
(концептуальной, логической и физической) состоит в способах
представления взаимосвязей между объектами. При проектировании БД
требуется различать взаимосвязи между объектами, между свойствами одного
объекта и между свойствами различных объектов. Рассмотрим каждую из них
более подробно.
Инфологическая модель данных
Предметная область – часть реального мира отражённая в базу данных.
Объединяя частные представления о содержимом базы данных, полученные в
результате опроса пользователей, и свои представления о данных, которые
могут потребоваться в будущих приложениях, АБД сначала создает
обобщенное неформальное описание создаваемой базы данных. Это описание,
выполненное с использованием естественного языка, математических формул,
таблиц, графиков и других средств, понятных всем людям, работающих над
проектированием базы данных, называют инфологической моделью данных.
Цель инфологического моделирования – обеспечение наиболее естественных
для человека способов сбора и представления той информации, которую
предполагается хранить в создаваемой базе данных. Поэтому инфологическую
модель данных пытаются строить по аналогии с естественным языком.
Основными конструктивными элементами инфологических моделей являются
сущности, связи между ними и их свойства (атрибуты).
Сущность – любой реальный или не реальный различимый объект (объект,
который мы можем отличить от другого), информацию о котором необходимо
хранить в базе данных. Сущностями могут быть люди, места, самолеты,
рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип
сущности и экземпляр сущности. Понятие тип сущности относится к набору
однородных личностей, предметов, событий или идей, выступающих как
целое. Экземпляр сущности относится к конкретной вещи в наборе.
Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев
и т.д.
Атрибут – поименованная характеристика сущности. Атрибутом сущности
является любая деталь, которая служит для уточнения, идентификации,
классификации, числовой характеристики или выражения состояния сущности.
Его наименование должно быть уникальным для конкретного типа сущности,
но может быть одинаковым для различного типа сущностей (например, ЦВЕТ
может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и
т.д.). Атрибуты используются для определения того, какая информация
должна быть собрана о сущности. Примерами атрибутов для сущности
АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также
существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет
много экземпляров или значений: Красный, Синий, Банановый, Белая ночь и
т.д., однако каждому экземпляру сущности присваивается только одно
значение атрибута.
Абсолютное различие между типами сущностей и атрибутами отсутствует.
Атрибут является таковым только в связи с типом сущности. В другом
контексте атрибут может выступать как самостоятельная сущность.
Например, для автомобильного завода цвет – это только атрибут продукта
производства, а для лакокрасочной фабрики цвет – тип сущности.
Связь – ассоциирование двух или более сущностей. Эта ассоциация всегда
является бинарной и может существовать между двумя разными сущностями
или между сущностью и ей же самой (рекурсивная связь). В любой связи
выделяются два конца (в соответствии с существующей парой связываемых
сущностей), на каждом из которых указывается имя конца связи, степень
конца связи (сколько экземпляров данной сущности связывается),
обязательность связи (т.е. любой ли экземпляр данной сущности должен
участвовать в данной связи).
Если бы назначением базы данных было только хранение отдельных, не
связанных между собой данных, то ее структура могла бы быть очень
простой. Однако одно из основных требований к организации базы данных –
это обеспечение возможности отыскания одних сущностей по значениям
других, для чего необходимо установить между ними определенные связи. А
так как в реальных базах данных нередко содержатся сотни или даже тысячи
сущностей, то теоретически между ними может быть установлено более
миллиона связей. Наличие такого множества связей и определяет сложность
инфологических моделей.
При определении инфологической модели необходимо принимать во внимание
следующее:
База данных должна удовлетворять актуальным информационным потребностям
организации. Получаемая информация должна по структуре и содержанию
соответствовать решаемым задачам.
База данных должна обеспечивать получение требуемых данных за приемлемое
время, то есть отвечать заданным требованиям производительности.
База данных должна удовлетворять выявленным и вновь возникающим
требованиям всех пользователей.
База данных должна легко расширяться при реорганизации и расширении
предметной области.
База данных должна легко изменяться при изменении программной и
аппаратной среды.
Инфологическая модель данных “сущность-связь”
Инфологическая модель отображает реальный мир в некоторые понятные
человеку концепции, полностью независимые от параметров среды хранения
данных. Существует множество подходов к построению таких моделей:
графовые модели, семантические сети, модель “сущность-связь” и т.д.
Наиболее популярной из них оказалась модель “сущность-связь” или
называемая ещё ER-моделью (от англ. Entity-Relationship, т.е.
сущность-связь).
На использовании разновидностей ER-модели основано большинство
современных подходов к проектированию баз данных (главным образом,
реляционных). Модель была предложена Ченом (Chen) в 1976 г.
Моделирование предметной области базируется на использовании графических
диаграмм, включающих небольшое число разнородных компонентов. В связи с
наглядностью представления концептуальных схем баз данных ER-модели
получили широкое распространение в системах CASE, поддерживающих
автоматизированное проектирование реляционных баз данных.
В них сущности изображаются помеченными прямоугольниками, ассоциации
(связи)– помеченными ромбами или шестиугольниками, атрибуты –
помеченными овалами, а связи между ними – ненаправленными ребрами, над
которыми может проставляться степень связи (1 или буква, заменяющая
слово “много”) и необходимое пояснение.
Между двумя сущностям, например, А и В возможны четыре вида связей.
Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому
представителю (экземпляру) сущности А соответствует 1 или 0
представителей сущности В:
Студент может не “заработать” стипендию, получить обычную или одну из
повышенных стипендий. Или, допустим, в определенный момент времени один
клиент может сделать только один заказ. В этом случае между объектами
КЛИЕНТ и ЗАКАЗ устанавливается взаимосвязь «один к одному», обозначаемая
одинарными стрелками.
Между данными, хранящимися в объектах КЛИЕНТ и ЗАКАЗ, будет существовать
взаимосвязь, в которой каждая запись в одном объекте будет однозначно
указывать на запись в другом объекте. Ни в одном, ни в другом объекте не
может существовать записи, не связанной с какой-либо записью в другом
объекте.
Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А
соответствуют 0, 1 или несколько представителей сущности В.
Квартира может пустовать, в ней может жить один или несколько
жильцов.Или, например, в определенный момент времени один клиент может
стать обладателем нескольких моделей автомобилей, при этом несколько
клиентов не могут являться обладателями одного автомобиля. Взаимосвязь
«один ко многим» можно обозначить с помощью одинарной стрелки в
направлении к «одному» и двойной стрелки в направлении ко «многим» .В
этом случае одной записи данных первого объекта (его часто называют
родительским или основным) будет соответствовать несколько записей
второго объекта (дочернего или подчиненного). Взаимосвязь «один ко
многим» очень распространена при разработке реляционных баз данных.
Третий тип – связь МНОГИЕ-К-ОДНОМУ (М:1): одному представителю сущности
B соответствуют 0, 1 или несколько представителей сущности А.
В принципе нет никакой разницы между связью ОДИН-КО-МНОГИМ и
МНОГИЕ-К-ОДНОМ, т.к. между двумя сущностями возможны связи в обоих
направлениях и всё зависит от того с какими сущностями связаны данные.
Четвёртый тип – связь МНОГИЕ-КО-МНОГИМ (N:М): одному представителю
сущности B соответствуют 0, 1 или несколько представителей сущности А и
одновременно одному представителю сущности А соответствуют 0, 1 или
несколько представителей сущности В.
Это также обусловлено тем, что между двумя сущностями возможны связи в
обоих направлениях.
Если связь между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ называется БРАК, то
существует четыре возможных представления такой связи:
Или например каждый продавец может обслуживать нескольких клиентов. С
другой стороны, приобретая автомобили в различное время, каждый клиент
вполне может быть обслужен различными продавцами. Между объектами КЛИЕНТ
и ПРОДАВЕЦ существует взаимосвязь «многие ко многим». Такая взаимосвязь
обозначается двойными стрелками.
Характер связей между сущностями не ограничивается перечисленными.
Существуют и более сложные связи:
множество связей между одними и теми же сущностями
(пациент, имея одного лечащего врача, может иметь также несколько
врачей-консультантов; врач может быть лечащим врачом нескольких
пациентов и может одновременно консультировать несколько других
пациентов);
тренарные связи:
связи более высоких порядков, семантика (смысл) которых иногда очень
сложна.
В приведенных примерах связей не показаны атрибуты сущностей и
ассоциаций во всех ER-диаграммах. Так, ввод лишь нескольких основных
атрибутов в описание брачных связей значительно усложнит ER-диаграмму
(рис. 2.1,а). В связи с этим язык ER-диаграмм используется для
построении небольших моделей и иллюстрации отдельных фрагментов больших.
Чаще же применяется менее наглядный, но более содержательный язык
инфологического моделирования (ЯИМ), в котором сущности и ассоциации
представляются предложениями вида:
СУЩНОСТЬ (атрибут 1, атрибут 2 , …, атрибут n)
АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, …]
(атрибут 1, атрибут 2, …, атрибут n)
где S – степень связи, а атрибуты, входящие в ключ, должны быть отмечены
с помощью подчеркивания.
Так, рассмотренный выше пример множества связей между сущностями, может
быть описан на ЯИМ следующим образом:
Врач (Номер_врача, Фамилия, Имя, Отчество, Специальность)
Пациент (Регистрационный_номер, Номер койки, Фамилия,
Имя, Отчество, Адрес, Дата рождения, Пол)
Лечащий_врач [Врач 1, Пациент M]
(Номер_врача, Регистрационный_номер)
Консультант [Врач M,Пациент N]
(Номер_врача, Регистрационный_номер).
Для примера ER-диаграмма базы данных “Питание” показана на рис. а
модель на языке ЯИМ имеет следующий вид:
Блюда (БЛ, Блюдо, Вид)
Продукты (ПР, Продукт, Калорийность)
Поставщики (ПОС, Город, Поставщик) [Город]
Состав [Блюда M, Продукты N] (БЛ, ПР, Вес (г))
Поставки [Поставщики M, Продукты N] (ПОС, ПР, Дата_П, Цена, Вес (кг))
Города (Город, Страна)
Рецепты (БЛ, Рецепт) {Блюда}
Расход (БЛ, Дата_Р, Порций) {Блюда}
В этих моделях Блюдо, Продукт и Поставщик – наименования, а БЛ, ПР и ПОС
– цифровые коды блюд, продуктов и организаций, поставляющих эти
продукты.
составляющих. Именно этот тип диаграмм будет использоваться при
построении инфологической модели базы данных, разрабатываемой в данной
дипломной работе.
Даталогическая модель данных
Описание, создаваемое по инфологической модели данных, называют
даталогической моделью данных. Даталогическая модель отражает логические
связи между элементами данных вне зависимости от их содержания и среды
хранения. Пользователям выделяются подмножества этой логической модели,
называемые внешними моделями, отражающие их представления о предметной
области. Внешняя модель соответствует представлениям, которые
пользователи получают на основе логической модели, в то время как
концептуальные требования отражают представления, которые пользователи
первоначально желали иметь и которые легли в основу разработки
инфологической модели. Даталогическая модель отображается в физическую
память, такую, как диск, лента или какой-либо другой носитель
информации. Даталогическая
модель в основном используется прикладными программистами для реализации
требований, которые выдвинули конечные пользователи, отражённых в
инфологической концептуальной модели.
Типы даталогических моделей уже обсуждались нами ранее. Это есть не что
иное, как Модели представления данных, т.о. даталогическая модель данных
может быть реляционной, иерархической или сетевой.
При разработке даталогической модели, кроме требований предъявляемых для
построения инфологической модели, предъявляются дополнительные
требования:
Загруженные в базу данных корректные данные должны оставаться
корректными.
Данные до включения в базу данных должны проверяться на достоверность.
Доступ к данным, размещаемым в базе данных, должны иметь только лица с
соответствующими полномочиями.
Разрешение проблем, возникающих при одновременном запросе одних и тех же
данных многими пользователями (прикладными программами);
Способы обеспечения защиты данных от некорректных обновлений и (или)
несанкционированного доступа;
Если инфологическая модель данных предназначена для наглядного отражения
представления пользователей т.е. является человеко-ориентированной, то
даталогическая модель уже является компьютеро-ориентированной. С её
помощью СУБД дает возможность программам и пользователям осуществлять
доступ к хранимым данным лишь по их именам, не заботясь о физическом
расположении этих данных.
Переход от ER – модели к реляционной.
Переход от инфологической модели “сущность-связь”- это сравнительно
простая задача, поскольку в терминологии и принципах ER-модели и
реляционного подхода имеется взаимно однозначное соответствие.
Существует ряд хорошо зарекомендовавших себя правил с пощью которых из
ER-диаграмм отроются реляционные таблицы.
Каждая простая сущность превращается в таблицу. Простая сущность –
сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности
становится именем таблицы.
Каждый атрибут становится возможным столбцом с тем же именем; может
выбираться более точный формат. Столбцы, соответствующие необязательным
атрибутам, могут содержать неопределенные значения; столбцы,
соответствующие обязательным атрибутам, – не могут.
Компоненты уникального идентификатора сущности превращаются в первичный
ключ таблицы. Если имеется несколько возможных уникальных
идентификатора, выбирается наиболее используемый. Если в состав
уникального идентификатора входят связи, к числу столбцов первичного
ключа добавляется копия уникального идентификатора сущности, находящейся
на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для
именования этих столбцов используются имена концов связей и/или имена
сущностей.
Связи многие-к-одному (и один-к-одному) становятся внешними ключами.
Т.е. делается копия уникального идентификатора с конца связи “один”, и
соответствующие столбцы составляют внешний ключ. Необязательные связи
соответствуют столбцам, допускающим неопределенные значения;
обязательные связи – столбцам, не допускающим неопределенные значения.
Индексы создаются для первичного ключа (уникальный индекс), внешних
ключей и тех атрибутов, на которых предполагается в основном базировать
запросы.
Если в концептуальной схеме присутствовали подтипы, то возможны два
способа: все подтипы в одной таблице (а) или для каждого подтипа –
отдельная таблица (б). При применении способа (а) таблица создается для
наиболее внешнего супертипа, а для подтипов могут создаваться
представления. В таблицу добавляется, по крайней мере, один столбец,
содержащий код ТИПА; он становится частью первичного ключа. При
использовании метода (б) для каждого подтипа первого уровня (для более
нижних – представления) супертип воссоздается с помощью представления
UNION (из всех таблиц подтипов выбираются общие столбцы – столбцы
супертипа).
Имеется два способа работы при наличии исключающих связей: общий столбец
и явные внешние ключи (б). Если остающиеся внешние ключи все в одном
домене, т.е. имеют общий формат (способ (а)), то создаются два столбца:
идентификатор связи и идентификатор сущности. Столбец идентификатора
связи используется для различения связей, покрываемых дугой исключения.
Столбец идентификатора сущности используется для хранения значений
уникального идентификатора сущности на дальнем конце соответствующей
связи. Если результирующие внешние ключи не относятся к одному домену,
то для каждой связи, покрываемой дугой исключения, создаются явные
столбцы внешних ключей; все эти столбцы могут содержать неопределенные
значения.
Физическая модель данных
Физическая модель данных – модель, определяющая размещение данных на
внешних носителях, методы доступа и технику индексирования. Она так же
называется внутренней моделью системы.
Внешние модели (даталогические модели) никак не связаны с типом
физической памяти, в которой будут храниться данные, и с методами
доступа к этим данным. Внутренние модели (физические модели) наоборот
определяют и оперируют размещением данных и их взаимосвязях на
запоминающих устройствах.
Физическая организация данных оказывает основное влияние на
эксплуатационные характеристики БД. Разработчики СУБД пытаются создать
наиболее производительные физические модели данных, предлагая
пользователям тот или иной инструментарий для поднастройки модели под
конкретную БД. Существует большое разнообразие способов реализации и
корректировки физических моделей современных промышленных БД, что не
позволяет рассмотреть их подробно.
Физическая модель данных является полностью компьютерно-ориентированной
и конечные пользователи, а порой и прикладные программисты, не имеют
никакого представления о том, каким образом данные запоминаются и
извлекаются или каким способом организуются индексы в таблицах для
быстрого поиска или ссылочная целостность. Эти и множество других
функций по методам доступа и поддержании баз данных на внешних
носителях, а также способов поиска и доступа к данным в современных СУБД
обеспечивается в основном ядром базы данных, что значительно облегчает
задачу создания БД и их ведение.
Трехуровневая архитектура (инфологический, даталогический и физический
уровни) позволяет обеспечить независимость хранимых данных от
использующих их программ. АБД может при необходимости переписать
хранимые данные на другие носители информации и (или) реорганизовать их
физическую структуру, изменив лишь физическую модель данных. АБД может
подключить к системе любое число новых пользователей (новых приложений),
дополнив, если надо, даталогическую модель. Указанные изменения
физической и даталогической моделей не будут замечены существующими
пользователями системы (окажутся “прозрачными” для них), так же как не
будут замечены и новые пользователи. Следовательно, независимость данных
обеспечивает возможность развития системы баз данных без разрушения
существующих приложений.
Этапы проектирования базы данных
Этапы проектирования базы данных с учетом рассмотренных выше аспектов:
Проектирование инфологической концептуальной модели баз данных:
а) Исследование предметной области применения и выявление требований
конечных пользователей и решаемых задач.
в) Анализ данных: сбор основных данных (объекты, связи между объектами).
с) Построение ER-диаграммы базы данных.
Проектирование даталогической модели базы данных (учитывать требования
СУБД ).
a) Потенциально возможные прикладные программы: сбор информации о
потенциальных возможностях использования данных.
Проектирование физической модели базы данных (оценка эксплуатационных
характеристик прикладных программ).
Реализация базы данных (оценка при неудовлетворительных эксплуатационных
характеристиках).
По этой схеме производилась реализация базы данных “Деканат”, являющейся
конечной целью данной дипломной работы.
Практическая часть
Предметная область и задачи, возложенные на базу данных
База данных предназначена для хранения данных об обучающихся студентах,
а также оценок успеваемости по списку изучаемых дисциплин (программе
обучения). Подразумевается, что эта информация может изменятся в течении
всего периода обучения и может быть затребована в любое время за период
обучения студента и даже после окончания его обучения или участвовать в
формировании статистических данных о группе или курсе за любой временной
промежуток. База данных несомненно носит характер фактографической
информационной системы и должна выдавать однозначные сведения на
поставленные запросы. Конечными пользователями базы данных являются
работники деканатов, которые относятся к категории пользователей не
искушенных в вопросах ведения, администрирования баз данных и
поддержании их в актуальном состоянии. Это накладывает определенные
требования на разработку системы управления базой данных, при которой
все методы доступа, поиска и большинство функций администрирования
скрыты внутри программы и прозрачны при работе что, несомненно, скажется
на разработке программного интерфейса. Кроме того, существующая на
данный момент в деканатах факультетов база данных по делам студентов,
диктует необходимость принимать во внимание вопросы совместимости и
конвертирования данных существующей базы данных в формат разрабатываемой
в данной дипломной работе. Более подробно все требования перечислены
ниже:
Предоставление общей информации об обучающихся студентах. Это
совокупность сведений о каждом студенте обучающегося в данный момент,
включает в себя общую информацию такую как фамилия, имя, отчество, дата
рождения и поступления, пол, национальность, адрес проживания, семейное
положение и состав семьи, а также информацию учебного характера, такую
как текущий курс, группа, подгруппа, изучаемый язык, специализация и
др. Подразумевается, что информация будет изменятся и пополнятся в
течении срока обучения.
Ведение архива студентов. После окончания срока обучения информация о
студентах может еще некоторое время быть необходимой (в бумажных архивах
университета она хранится в течении 75 лет), поэтому необходимо чтобы
студены окончившие обучение заносились в архив и хранились в нем в плоть
до принятия решения об их удалении.
Пополнение списка поступившими абитуриентами. В начале каждого учебного
года в базу данных должны заноситься студенты из числа абитуриентов
поступивших в текущем году.
Перевод факультета на следующий курс. После окончания учебного года
информация о текущем курсе каждого студента должна быть изменена т.е.
студент дожен быть переведен на следующий курс в случае успешного
завершения сессии. Эти изменения должны затрагивать только личностей из
действительного числа студентов и не касаться находящихся в архиве.
Кроме того, студенты считающиеся окончившими обучения должны быть
автоматически занесены в архив.
Распределение групп по специальностям. С этой задачей сталкиваются после
сдачи госэкзамена на 3 курсе, когда уже сформированные группы вновь
перераспределяются в зависимости от выбранной студентами специальности.
Распределения языка по группам. На первом курсе распределение студентов
по группам ведется в зависимости от изучаемого иностранного языка.
Предоставление А/О и возврат из А/О. В течении обучения студенту может
быть предоставлен академический отпуск на один год по его окончанию
студент продолжает обучение. В течение этого времени информация о
студенте должна храниться в архиве, чтобы быть востребованной при
восстановлении. Кроме того иногда требуется информация о дате ухода
студента в академический отпуск и номере приказа по которому
академический отпуск был предоставлен.
Отчисление и восстановление. На любом курсе студент может быть отчислен
по ряду причин. Однако факт отчисления не носит фатальный характер и в
ряде случаев у него есть возможность восстановиться. Т.о. вплоть до
факта восстановления информация должна храниться в архиве пока не будет
востребованной или не будет принято решение о нецелесообразности ее
хранения. В случае отчисления также требуется информация о дате
отчисления студента и номере приказа по которому отчисление произошло.
Перевод в другую группу/подгруппу. Эта задача часто имеет место на
первом курсе когда студенты изъявляют желание перейти в другую группу
или подгруппу когда окончательный состав группы еще полностью не
сформировался.
Предоставление информации об учебном плане. Дисциплины по которым
производится обучение в группах в общеобразовательный период и после
выбора специализации должны быть точно представленны. По ним ведутся
ведомости об итогах сессии для каждого студента.
Ведение информации об итогах сессии и проводимых аттестаций. В период
обучения каждый студент изучает дисциплины указанные в учебном плане и,
следовательно должен проходить контроль знаний по ним в конце каждого
семестра. Кроме того, в середине семестра производится дополнительный
контроль знаний по системе отличающегося от экзаменационного.
Получение статистической информации о факультете. Для анализа,
планирования и принятия решений о дальнейшем развитии факультета полезно
иметь информацию представленную в обобщенном виде (итоговых сумм,
таблиц, графиков), которую можно извлечь из информации об итогах
проведенных сессий, аттестаций и т.д.(количественная и качественная
успеваемость, количество задолжников по предметам, количество сдавших
экзамены и т.д.).
Определение объектов базы данных
Анализ определенных выше задач позволяет выделить сущности (объекты)
проектируемой базы данных и, построить ее инфологическую модель на языке
“Таблицы-связи”. В результате анализа были определены следующие объекты
базы данных:
Студенты (Номер студента, Тип_студента, Фамилия, Имя, Отчество,
Дата_рождения, Пол, Гражданство, Национальность, Образование,
Семейное_положение, Социальное_положение, Дата_поступления, Курс,
Группа, Подгруппа, Изучаемый_язык, Специализация, Место_жительства,
Телефон, Состав_семьи, Адрес_родителей).
Эта сущность отводится для хранения основных сведений о студентах.
Сведения могут быть как неизменяемые за весь период обучения (имя
отчество, дата рождения, пол и т.д.) так и изменяемые один раз или
многократно в течения периода обучения (курс, группа, подгруппа, место
жительства). Очевидно, что даже в пределах одной группы могут быть
однофамильцы или даже люди с одинаковыми фамилиями и именами, поэтому
однозначно определить записи по фамилии студентов не возможно. Поэтому
здесь введён атрибут Номер_Студента – уникальный числовой идентификатор
присваиваемый обучаемому студенту. В принципе этот идентификатор нет
необходимости знать для работы с базой данных и он может быть скрыт от
пользователей, он служит только для внутренних целей.
Отдельно необходимо сказать про атрибут Тип_Студента. Он был введён для
удобной реализации всех задач, выполняемых деканатом, по группировке
студентов и может принимать такие значения как Отчисленный,
Находящийся_в_академическом_отпуске, Обычный, Востановившийся и т. д.
Это освобождает от необходимости заводить отдельную таблицу, например,
на отчисленных студентов, а также упрощает операции обратного зачисления
в число студентов, если он решил восстановиться. Таким образом
исключается дублирование записей. Информация обо всех студентах хранится
в одном месте, что упрощает задачу сохранения целостности базы данных.
Дисциплины (Номер_дисциплины, Название, Тип_дисциплины).
Данная сущность отводится для хранения списка дисциплин участвующих в
формировании учебного плана, по которому производится обучение в группах
и, соответственно, оценка успеваемости каждого студента. Как и для
предыдущей сущности для каждую дисциплину однозначно определяет её номер
идентификатор, который автоматически увеличивается на единицу с вводом
каждой новой дисциплины. Атрибут Тип_дисциплины определяет классификацию
дисциплин и может принимать такие значения как: гуманитарная,
техническая, общеобразовательная и т. д.
ПланНаСеместр (Номер_дисциплины, Семестр, Лекции, Семинары,
Лабораторные_работы, Форма_контроля).
Данная сущность представляет собой расписание дисциплин по семестрам
т.е. учебный план. Первичный ключ этой сущности состоит из двух
атрибутов. Номер_дисциплины – тот самый уникальный идентификатор,
который определяет каждую запись в таблице “Дисциплины”. Атрибут Семестр
является просто номером семестра в котором планируется читать данную
дисциплину (на физическом факультете существует только дневная форма
обучения и весь период обучения занимает 10 семестров). Атрибуты Лекции,
Семинары, Лабораторные_работы определяют комплекс мероприятий, который
планируется проводить при обучении: они могут присутствовать или нет и
дают только исключительно дополнительную информацию. Атрибут
Форма_контроля может принимать значения зачет или экзамен. Сущность
также позволяет отобразить тот факт, что дисциплина может преподаваться
в течении нескольких семестров, причём в разных формах (лекции,
семинары, лабораторные работы) и их комбинациях с разными формами
контроля знаний по данной дисциплине в конце семестра.
ПланДляГруппы (Номер_дисциплины, Семестр, Номер_группы,
Номер_подгруппы).
Данная сущность отражает распределение дисциплин по группам (или, если
это необходимо, даже по подгруппам). Поэтому все четыре атрибута данной
сущности входят в состав первичного ключа. Здесь как и для сущности
ПланНаСеместр атрибуты Номер_дисциплины и Семестр однозначно определяют
какая дисциплина в данном семестре будет введена в программу обучения.
Атрибуты Номер_группы и Номер_подгруппы вносят сведения о том, в каких
группах данная дисциплина будет преподаваться. Эффективность такого
распределения дисциплин по группам проявляется на третьем курсе, когда
происходит распределение студентов по специальностям и идёт формирование
отдельных планов обучения для разных групп специализаций.
Экзамены (Номер_студента, Номер_дисциплины, Семестр, Результат).
Сущность отражает успеваемость студентов по дисциплинам указанных в
учебном плане. Атрибут Номер_студента – уникальный номер студента
присвоенный ему в сущности “Студенты”. Атрибут Номер_дисциплины
указывает на дисциплину определённую в таблице “Дисциплины”. Третий
атрибут первичного ключа – Семестр – введён для случая, когда дисциплина
читается в течение нескольких семестров и следовательно знания должны
быть оценены во всех семестрах согласно учебному плану. Атрибут
Результат представляет оценку по данной дисциплине, которая может быть
как числом (2,3,4,5), так и строкой (зачёт, незачёт).
Аттестация (Номер_студента, Номер_дисциплины, Семестр, Номер_атестации,
Результат).
Сущность отражает успеваемость студентов по аттестациям, которые
проводятся в течении семестра. Назначение атрибутов первичного ключа
Номер_студента, Номер_дисциплины, Семестр точно такое же, как и для
сущности “Экзамены”, только сюда введён дополнительный атрибут
Номер_атестации, который определяет номер аттестации. Количество
аттестаций в принципе не ограничено и определяется лишь учебным планом.
На физическом факультете в течение каждого семестра проводиться лишь две
аттестации.
Приказы (Номер_студента, Номер_приказа, Тип_приказа, Дата_приказа,
Причина).
Данная сущность отводится для хранения информации о приказах, на
основании которых производятся отчисления или восстановление студентов,
а также предоставления академического отпуска и возврат из него.
Первичный ключ составляет четыре атрибута. Атрибут Номер_приказа,
уникальный номер приказа, который приходит из отдела кадров студентов.
Атрибут Тип_Приказа может принимать такие значения как: отчисление,
восстановление, предоставление А/0, возврат из А/О. Поскольку на
практике могут встречаться такие случаи, что один и тот же студент может
быть несколько раз быть отчисленным, а затем восстановленным и к тому же
может взять академический отпуск, то для хранения достоверной информации
в состав первичного ключа введен атрибут Дата_Приказа, отражающий всю
хронологию подобных случаев. Атрибут Причина носит дополнительную
информацию о причине по которой производиться отчисление или
предоставляется академический отпуск.
ER-диаграмма базы данных
На рисунке ____ приведена схема инфологической модели базы данных на
языке “Таблицы-связи”.
Существование сущности ПланНаСеместр позволяет хранить учебный план
независимо от информации о группах, в которых читаются данные
дисциплины. Сущность ПланДляГруппы позволяет формировать учебный план
индивидуально для групп и подгрупп, что имеет место на практике на
третьем году обучения на физическом факультете. К этому времени
общеобразовательные дисциплины для всех групп уже в основном пройдены и
идёт формирование индивидуальных учебных планов для групп, которые
распределены по специализациям. Студент, будучи включённым в
какую-нибудь группу и подгруппу, автоматически получает учебный план
определённый для данной группы и т.о. автоматически можно получить
список дисциплин по которым знания студента должны быть оценены. Это
позволяет судить о том, справился или нет студент с учебным планом, что
может быть использовано для автоматического определения списка
неуспевающих студентов или подсчёта среднего бала и прочей статистики.
Подчинённость сущности “ПланНаСеместр” по отношению к сущности
“Дисциплины” позволяет определить преподавание дисциплины на несколько
семестров, что довольно часто имеет место на практике.
Аналогично подчинённая структура типа “один-ко-многим” для пары
сущностей “Студенты”(”Приказы” позволяет производить несколько раз для
студентов операции отчисления, восстановления, предоставления
академического отпуска и т. д. Что также встречается на практике. При
этом информация о студентах не удаляется из базы данных. Студент лишь
переводится в другую категорию, например “отчисленные”, и вся информация
храниться в базе данных до тех пор пока не будет востребована или не
будет принято решение о её удалении.
Подчинённая структура сущностей базы данных налагает требования по
заполнению базы данных информацией. Например, прежде должны быть
заполнены главные таблицы “Студенты” и “Дисциплины”, составлен учебный
план, а только потом согласно учебному плану можно заполнять
информацией таблицы “Экзамены” и “Аттестация”. Эта особенность должна
быть отражена в интерфейсе взаимодействия базы данных с конечным
пользователем.
Как видно из схемы первичные ключи сущностей “Студенты” и “Дисциплины”
играют важную роль не только в однозначной идентификации записей в
данной сущности, но и выполняют связующую роль в организации связей типа
“один-ко-многим” между таблицами.
Даталогическая модель базы данных
В качестве даталогической модели базы данных была выбрана реляционная
модель, поскольку именно реляционная модель является результатом более
развитых представлений о формировании и ведении баз данных, на которые
наложен строгий математический аппарат. Реляционные модели наиболее
логично и наглядно отражают структуру хранимой информации и внутренних
связей, что позволяет более полно анализировать структуру базы данных
при разработке. Это привело к тому, что именно реляционные модели баз
данных наиболее распространены в настоящее время и являются стандартом,
на который переводятся все существовавшие ранее базы данных с
иерархической и сетевой моделью. Ещё одним веским доводом в пользу
выбора реляционной модели является тот факт, что подавляющее большинство
предоставляемых средств для разработки баз данных ориентированны
исключительно на реляционную модель. Кроме того, реляционные базы данных
в последствии легче расширять и интегрировать, что является неотъемлемой
частью дальнейшего развития баз данных с увеличением возлагаемых на них
задач.
Инфологическая модель базы данных легко отображается в реляционную
даталогическую модель, используя описанные ранее правила по переводу. В
результате получается семь таблиц реляционной базы данных, где каждая
сущность напрямую отражается в отдельную таблицу, атрибуты каждой
сущности становятся полями этой таблицы, а первичные ключи сущности
становятся первичными ключами таблицы. На данном этапе необходимо также
провести нормализацию полученных таблиц с целью устранения избыточности
данных. Эта процедура в дальнейшем значительно облегчит усилия, которые
будут затрачиваться на поддержании таблиц базы данных в целостном
состоянии.
Если проанализировать значения полей таблицы “Студенты”, то видно, что
некоторые поля, такие как, Тип_студента, Образование,
Семейное_положение, Социальное_положение, принимают некоторые значения
из ограниченного набора, кроме того, эти значения представляют собой
текстовые константы, которые могут быть довольно большие по длине.
Аналогичными свойствами обладают поля Тип_дисциплины, Форма_контроля,
Тип_приказа других таблиц. Такие значения лучше всего хранить в
отдельной таблице со своими уникальными номерами, а вместо этих длинных
строк подставлять значение уникальных номеров, которые назначены каждой
строке. Это позволит сократить дисковое пространство для хранения
данных. Пользователь, таким образом, может выбрать некоторые значения
этих полей из предложенного в списке, что несколько ускорит процесс
заполнения базы данных, поскольку освобождает его от набора длинной
последовательности одних и тех же строк.
Правила нормализации, описанные ранее, предписывают для таких случаев
заводить отдельную таблицу для каждого поля и хранить в ней все значения
характерные только для одного поля. Я же принял решение свести значения
для всех полей в одну таблицу и различать их не только по уникальному
номеру-идентификатору, но и указывать таблицу, к которой это поле
принадлежит, а также название самого поля. Выбор такого варианта
оправдан тем, что таких полей в таблицах базы данных более десяти.
Организация отдельных таблиц для каждого такого поля существенно
усложнит структуру базы данных. Кроме того добавление новых атрибутов с
подобным ограниченным числом значений потребует организовывать новую
таблицу и затрату больших усилий по изменению интерфейса взаимодействия
с конечным пользователем и исправлению программного кода, нежели от
добавления этих значений в одну универсальную таблицу.
Конечно, в этом случае таблицы базы данных не будут до конца
нормализованы, что накладывает некоторые требования на процедуры
поддержания базы данных в целостном состоянии, но даёт возможность
“безболезненных изменений” в программном коде, что может существенно
сократить время разработки в дальнейшем. Процедуры по поддержанию
целостности можно реализовать в программном коде, сделав их таким
образом прозрачными для конечного пользователя.
Таким образом, в результате нормализации таблиц базы данных и
проведённого анализа состава полей этих таблиц получилась ещё одна
таблица, содержащая значения тех полей, которые принимают ограниченное
число значений. Состав полей, первичный ключ (выделен жирным шрифтом с
курсивом) и описание полей представлены в таблице ______.
Такой состав таблиц позволяет выполнять все возложенные задачи,
поскольку он выведен из инфологической модели, проектируемой исходя из
требований конечных пользователей.
Физическое описание модели
База данных организованна в популярном формате локальных баз данных
Paradox. Этот формат для организации реляционных баз данных довольно
распространен, поскольку обладает наиболее развитой системой хранимых
типов данных, возможностями индексирования полей, что позволяет получать
доступ к данным за минимальное время, а также функциями по обеспечению
ссылочной целостности между реляционными таблицами, что позволяет
разработчику минимизировать временные затраты на создание базы данных, а
конечному пользователю затраты на поддержание целостности хранимых
данных и получения из базы данных самих хранимых данных. Поскольку базы
данных Paradox – реляционные базы данных, то запросы к данным
осуществляются с помощью реляционного языка запросов SQL. Благодаря
развитой системе определения ключевых полей и индексов при создании
таблиц запросы будут выполняться с минимальными временными затратами.
Хотя этот фактор для локальных баз данных не является ключевым, однако,
при росте объема хранимых данных именно скорость выполнения запросов
становиться решающим фактором при выборе формата баз данных.
Типы данных, хранимые в таблицах Paradox, очень разнообразны. Это и
символьные значения и разнообразные типы числовых значений, включающие
целочисленные, вещественные, вещественные с плавающей запятой, числа в
двоичном и двоично-десятичном формате, логические типы, специальные
форматы для хранения значений даты, времени и денежных сумм, графические
типы для хранения графических изображений в самых популярных форматах, а
также строковые значения неограниченной длины (в том числе и
форматированные в формате rtf) и даже типы поддерживаемые технологией
OLE (Object Linking and Embedding) фирмы Micrоsoft. Такое разнообразие
типов данных может отвечать даже самым изысканным задачам, которым
призвана служить создаваемая база данных и без сомнения подходит для
решения круга задач возложенного на базу данных DEKANAT для деканата
физического факультета.
База данных DEKAHAT представлена 8-ю таблицами (или по терминологии
реляционных баз данных – 8-ю реляционными отношениями): Students,
Discipls, PlanSemestr, PlanGroupe, Examine, Certifications, Orders,
Values. Рассмотрим структуру каждой более подробно.
В таблице Students представлена информация о студентах общего и
учебного характера. Поля, их типы, и назначение представлены в таблице
2.
Первичным ключем таблицы является поле Nstudent, которое однозначно
определяет каждую запись в таблице. Отказ использовать поле Family в
качестве первичного ключа подиктовано соображением того что даже в
пределах одной группы могут встречаться однофамильцы и при этом
требование уникальности ключа нарушится.
Поле StudType введено из соображений того, что в базе данных будут
одновременно храниться информация и об обычных студентах и о находящихся
в архиве. Это поле однозначно определяет к какой категории относится
данный студент.
Некоторые поля обозначающие однотипную информацию, например поля
Education, FamilyPosition, FamilyComposition, Spesiality и т. д. Имеют
целочисленный тип, в котором закодировано определенное значение.
Значения этих кодов сведены в таблицу Valuess, что продиктовано
соображениями экономии памяти на дисковом пространстве.
В таблице Discipls представленна информация об учебных дисциплинах,
которыми представлен учебный план. Поля, их типы, и назначение
представленны в таблице 3.
Первичным ключем является поле Ndis, однозначно определяющее любую
запись в таблице. Поле TypeDis как и впредыдущей таблице закодировано и
его значение также содержится в таблице Valuess.
В таблице PlanSemestr представлена информация об учебных планах на
семестр. Поля, их типы, и назначение представленны в таблице 4.
Поле Ndis содержит ссылку на таблицу Discipls, где представлены
непосредственно названия дисциплин и их характеристики. Поле Control
имеет закодированное значение, расшифровка которого осуществляется в
таблице Valuess. Первичным ключом является совокупность двух полей Ndis
и Semestr.
В таблице PlanGroupe представлена информация об учебных планах для
групп. Поля, их типы, и назначение представлены в таблице 5.
Все поля таблицы представлены целочисленным типом. Кроме того, поле Ndis
как и в таблице PlanSemestr поддерживает ссылочною целостность с
таблицей Discipls. Ключом данной таблицы является совокупность всех его
полей.
В таблице Orders представлена информация о приказах по которым
происходит отчисление, восстановление, предоставление А/О и возврат из
А/О. Поля, их типы, и назначение представлены в таблице 6.
Первичным ключем является совокупность полей Nstudent, Norder, TypeOrder
. Поле Nstudent ссылается на одноименное поле в таблице STUDENTS. Поля
TypeOrder и Motive закодированы и их расшифровка представленна в таблице
Valuess.
В таблице Examine представленна информация о результатах сессии. Поля,
их типы, и назначение представленны в таблице 7.
Первичным ключем является совокупность полей Nstudent, Ndis, Semestr
т.о. таблица спомощью полей Nstudent, Ndis связана с таблицами Students
и Discipls.
В таблице Certifications представленна информация о результатах
аттестации. Поля, их типы, и назначение представленны в таблице 8.
Она аналогична таблице Examine.
Таблица Valuess представлена четырьмя полями, из которых поля TableName,
FieldName, Code являются первичным ключем. К этой таблице ссылаются
большинство таблиц бызы данных DEKANAT, поскольку в ней хранятся
значения закодированных полей соответствующей таблицы.
Такой способ представления данных является наиболее удобным, поскольку
позволяет легко сохранять целостность базы данных, т.к. данные
находятся в одном месте и при изменении значения нет необходимости
изменять значения во всех записях таблицы, использующих это значение.
Програмная реализация
Все описанные таблицы функционируют в рамках созданной системы
управления базой данных ”DBDekanat”. СУБД ”DBDekanat” создана средствами
среды программирования Delphi 3.0 и реализует все необходимые требования
которые предъявлялись в постановке задания к настоящей дипломной работе
и выполняет полный круг задач требуемый от базы данных DEKANAT,
перечисленный выше.
В основу создания данной СУБД положен принцип экономии времени и усилий
конечного пользователя, т.е. работников деканата, предполагая, что
машина берет на себя все рутинные функции управления и доступа к
хранимым данным. Этот принцип прослеживался во всех моментах реализации
данной СУБД, включая создание удобного интерфейса для работой с этим
программным продуктом, продуманной структурой реляционных таблиц,
выбранным форматом баз данных выполняющие SQL-запросы за наиболее
короткое время. Даже функции администрирования базы данных не требуют
знакомства с теорией реляционной баз данных, СУБД самостоятельно
тестирует находящиеся в базе данных записи и производит приведение базы
данных к целостному состоянию. Пользователю остается согласиться со всей
проделанной работой (или ее частью) или провести все самостоятельно. За
сохранность введенных данных можно не беспокоиться поскольку никакая
информация
внесенная в базу данных не может быть удалена без подтверждения
пользователя.
Среди возможностей ”DBDekanat” следует выделить средство для создания
Т.о. СУБД ”DBDekanat” может явным образом конкурировать с существующей
в настоящее время СУБД.
Описание к СУБД ”DBDekanat” приведено в приложении 1.
Заключение
Главным результатом проведенной работы является создание функционирующей
СУБД, которая выполняет требуемый круг задач по ведению и использованию
базы данных для деканата физического факультета.
Реализация данного проекта была проведена без привлечения мощных средств
работы с базами данных, которые очень громоздки, поскольку носят
универсальный характер и к тому же требуют необходимую базу знаний по
теории баз данных.
Использование мощных средств Delphi 3.0 по созданию приложений
работающих в операционной системе Windows и в частности приложений баз
данных, позволило создать программный продукт максимально
ориентированный на конечного пользователя, который не искушен в вопросах
теории баз данных.
Вся необходимая работа по осуществлению методов доступа к информации
хранимой в базе данных, её модификации, поддержании базы данных в
целостном виде скрыта внутри и пользователю нет необходимости знать о
ней, чтобы успешно решать весь круг возникающих задач связанных с
использованием информации хранимой базе данных. Более того, программный
интерфейс максимально облегчает работу по обращению с базой данных
(вплоть до выбора из предложенного числа вариантов). Даже обращение к
базе данных со сложными запросами осуществляется в таком виде, что
структура возвращаемых данных видна еще до его исполнения.
Круг предъявляемых задач довольно широк. Они решаются в рамках данной
СУБД, с максимальной простотой, удобством и скоростью. Данный продукт
без сомнения может конкурировать с существующей базой данных и
средствами управления ею.
Рис. 14. Уровни моделей данных.
Рис. . Инфологическая модель базы данных на языке “Таблицы-связи”.
Номер_студента
Номер_приказа
Тип_приказа
Дата_приказа
Причина
Приказы
Номер_студента
Номер_дисциплины
Семестр
Номер_атестации
Результат
Аттестация
Номер_студента
Номер_дисциплины
Семестр
Результат
Экзамены
Номер_дисциплины
Семестр
Номер_группы
Номер_подгруппы
ПланДляГруппы
Номер_дисциплины
Семестр
Лекции
Семинары
Лабораторные_работыФорма_контроля
ПланНаСеместр
Номер_дисциплины
Название
Тип_дисциплины
Дисциплины
Номер_Студента
Тип_студента
Фамилия
Имя
Отчество Дата_рождения
Пол
Гражданство Национальность Образование
Семейное_положение
Социальное_положение Дата_поступления
Курс
Группа
Подгруппа Изучаемый_язык Специализация
Место_жительства
Телефон
Состав_семьи
Адрес_родителей
Студенты
Таблица 1.
Имя поля Описание
Имя_таблицы Название таблицы к которой принадлежит поле
Имя_поля Название поля в этой таблице
Код Уникальный номер (код) для значения данного поля
Значение Значение для поля с данным кодом
Таблица 2.
Имя поля Тип поля Описание
Family String[30] Фамилия
Name String[20] Имя
SecondName String[20] Отчество
BirthDate Date Дата рождения
Sitizen Integer Гражданство
Nationality Integer Национальность
Sex Integer Пол
Education Integer Образование
FamilyPosition Integer Семейное положение
FamilyComposition Integer Состав семьи
SocialPosition Integer Социальное положение
EnterDate Date Дата поступления
Groupe Integer Группа
Podgroupe Integer Подгруппа
Course Integer Курс
Spesiality Integer Специализация
Language Integer Изучаемый язык
City String[20] Город
Улица
Дом и Квартира по месту жительства
Street String[20]
House String[10]
Apartment String[5]
PFamily String[30] Фамилия родителей
PName String[20] Имя родителя
PsecondName String[20] Отчество родителя
Pcity String[20] Город в кот. Проживают
Padress String[30] Адрес родителей
StudType Integer Тип студента
NStudent Integer Номер студента (ключ).
Таблица 3.
Имя поля Тип поля Назначение
Ndis Integer Номер дициплины
NameDis String[30] Название дисциплины
TypeDis Integer Тип дисциплины
Таблица 4.
Имя поля Тип поля Назначение
Ndis Integer Номер дисциплины
Semestr Integer Cеместр
Lection Boolean Лекции
Seminars Boolean Семинары
LabWork Boolean Лаб. Работы
Control Integer Форма контроля
Таблица 5.
Имя поля Тип поля Назначение
Ndis Integer Номер дисциплины
Semestr Integer Семестр
Groupe Integer Номер группы
Podgroupe Integer Номер подгруппы
Таблица 6.
Имя поля Тип поля Назначение
Nstudent Integer Номер студента
Norder Integer Номер приказа
TypeOrder Integer Тип приказа
DateOrder Date Дата приказа
Motive Integer Причина
Таблица 7.
Имя поля Тип поля Назначение
Nstudent Integer Номер студента
Ndis Integer Номер дисциплины
Semestr Integer Номер семестра
Result Integer Оценка
Таблица 8.
Имя поля Тип поля Назначение
Nstudent Integer Номер студента
Ndis Integer Номер дисциплины
NSert Integer Номер аттестации
Result Integer Оценка
Таблица 9.
Имя поля Тип поля Назначение
TableName String Название таблицы
FieldName String Название поля
Code Integer Код
Value String Значение кода
Нашли опечатку? Выделите и нажмите CTRL+Enter
