Этапы разработки базы данных в среде Microsoft Access 2003

 

Содержание

Введение

1. Этапы проектирования базы данных

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

2.1 Анализ предметной области

2.2 Построение семантической модели БД

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

3.1 Понятие erd-диаграммы

3.2 Определение сущностей и атрибутов

3.3 Нормализация данных, понятие нормальной формы

3.4 Первая нормальная форма

3.5 Вторая нормальная форма

3.5.1 Определение ключевых полей

3.5.2 Установка связей между сущностями

3.6 Третья нормальная форма

3.7 Проверка адекватности логической модели

3.8 Установление параметров связей между сущностями

3.8.1 Определение типа и мощности связей

3.8.2 Задание правил декларативной ссылочной целостности

3.9 Установление альтернативных ключей, инверсных входов и определение типов атрибутов

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

4.1 Переход к физическому уровню модели

4.2 Денормализация данных

4.3 Корректировка типов и размеров полей

4.4 Проверка структурной целостности модели данных

4.5 Генерация системного каталога базы данных

4.6 Задание правил валидации

4.6.1 Общее понятие правил валидации

4.6.2 Задание правил проверки вводимых значений

4.6.3 Создание списка допустимых значений

5. Проектирование на уровне MS Access 2003

5.1 создание запросов

5.2 Создание отчётов

6. Разработка приложения

6.1 Разработка структуры приложения

6.1.1 Разработка режима пользователя

6.1.2 Разработка режима администратора

6.2 Создание главной кнопочной формы

Заключение

Список источников

Приложение

Введение

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

Одним из таких средств является Microsoft Access 2003 - реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.

Основные компоненты MS Access:

·построитель таблиц;

·построитель экранных форм;

·построитель SQL-запросов;

·построитель отчётов, выводимых на печать.

Они могут вызывать скрипты на языке VBA, поэтому MS Access позволяет разрабатывать приложения и БД практически "с нуля" или написать оболочку для внешней БД.Access является файл-серверной СУБД и потому применима лишь к маленьким приложениям. Отсутствует ряд механизмов, необходимых в многопользовательских БД, таких, например, как триггеры.

Данный курсовой проект имеет как теоретическую, так и программную части. Программная составляющая данной курсовой работы будет выполнена в среде Microsoft Access 2003.

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

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

В ходе выполнения курсовой работы будут использованы такие программные средства как CA ERwin Data Modeler 7.3, CA Erwin Data Model Validator 7.3 и Microsoft Access 2003.ERwin Data Modeler (ранее называвшийся AllFusion Process Modeler) - программный продукт в области реализации средств CASE-технологий.

Позволяет проводить описание, анализ и моделирование модели данных - построитель мета-моделей данных. Занимает одно из лидирующих мест в своём сегменте рынка. В настоящее время выпускается компанией Computer Associates. Распространяется на коммерческой основе.ERwin Data Model Validator - инструмент для проверки структуры баз данных и моделей, создаваемых в CA ERwin Data Modeler, позволяющий выявлять недочеты и ошибки проектирования. Гибкость CA ERwin Data Model Validator заключается в том, что можно проводить выборочные тесты, а также анализировать отдельные таблицы. Продукт дополняет функциональность CA ERwin Data Modeler, автоматизируя трудоемкую задачу поиска и исправления ошибок, одновременно повышая квалификацию проектировщиков баз данных, благодаря встроенной системе обучения.

база программное обеспечение access

1. Этапы проектирования базы данных

Проектирование базы данных проходит в три этапа.

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

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

Логическое (даталогическое) проектирование - создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель - набор схем отношений, обычно с указанием первичных ключей, а также "связей" между отношениями, представляющих собой внешние ключи.

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

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

Физическое проектирование - создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.

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

2.1 Анализ предметной области

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

Основные задачи отдела кадров:

·Кадровое обеспечение деятельности университета.

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

·Ведение учета по качественному составу ППС, наличие ученой степени и ученого звания.

·Обеспечение мероприятий по формированию корпоративной культуры (награждения юбиляров и т.д.)

·Запрос у руководителей структурных подразделений и должностных лиц вуза необходимые данные о работниках, а при приеме на работу и перемещениях работников - мнение руководителей соответствующих подразделений о целесообразности предлагаемых кадровых перестановок.

2.2 Построение семантической модели БД

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

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

Выделив 4 больших смысловых блока данных, я получил следующую картину (Табл.1-4)

Таблица 1

Информация о сотруднике

№ПолеТипРазмерОписание1PersonIDЧисловой5Регистрационный номер сотрудника2NameТекстовый40ФИО сотрудника3BirthДатаАвтоДата рождения сотрудника4PlaceТекстовый20Место рождения5AddressТекстовый60Домашний адрес сотрудника6PhoneТекстовый15Домашний телефон сотрудника7PassportТекстовый20Номер паспорта8PassportDateДатаАвтоДата выдачи паспорта9RegionТекстовый40Кем выдан паспорт10PictureПоле OLEАвтоФотография сотрудника

Таблица 2

Информация о предыдущих местах работы

1WorkBeginДатаАвтоДата начала трудовой деятельности2WorkEndДатаАвтоДата окончания трудовой деятельности3WorkТекстовый20В качестве кого работал4WorkPlaceТекстовый20Название предприятия5WorkAddressТекстовый60Адрес предприятия6WorkPhoneТекстовый15Телефон предприятия7ReasonТекстовый30Причина увольнения8PenaltyПоле MemoАвтоСведения о взысканиях9RewardsПоле MemoАвтоСведения о награждениях

Таблица 3

Информация о текущем месте работы

1DepartmentТекстовый40Название кафедры, на которой работает2InstituteТекстовый40Название института (департамента) 3PostТекстовый20Занимаемая должность4CommentПоле MemoАвтоПримечания

Таблица 4

Информация об образовании сотрудника

1EducationТекстовый40Оконченный ВУЗ2YearЧисловой4Год окончания ВУЗа3SpecialityТекстовый30Специальность сотрудника4DegreeYesЛогический1Ученая степень (есть/нет) 5DegreeЧисловой1Ученая степень сотрудника6RankЧисловой1Ученое звание сотрудника

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

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

3.1 Понятие erd-диаграммы

После создания Концептуальной модели базы данных можно переходить к формированию логической модели, а для этого уже понадобятся дополнительные программные средства. В данной работе используется программа CA ERwin Data Modeler версии 7.3.

Первым шагом при создании логической модели БД является построение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты - прилагательными или модификаторами, взаимосвязи - глаголами.диаграмма позволяет рассмотреть систему целиком и выяснить требования, необходимые для ее разработки, касающиеся хранения информации.диаграммы можно подразделить на отдельные куски, соответствующие отдельным задачам, решаемым проектируемой системой. Это позволяет рассматривать систему с точки зрения функциональных возможностей, делая процесс проектирования управляемым.

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

Рис.1 Пример ERD-диаграммы

3.2 Определение сущностей и атрибутов

Сущность - это субъект, место, вещь, событие или понятие, содержащие информацию. Точнее, сущность - это набор (объединение) объектов, называемых экземплярами. В приведенном на рис.2 примере сущность "Работник" представляет всех возможных сотрудников университета. Каждый экземпляр сущности обладает набором характеристик. Так, каждый работник может иметь имя, адрес, телефон и т.д. В логической модели все эти характеристики называются атрибутами сущности.

Итак, я начинаю создание ERD-диаграммы для целевой БД. Первым шагом будет внесение имеющихся данных в 4 разные, не связанные между собой сущности. Называться сущности будут "Работник", "Образование", "Предыдущее место работы" и "Текущее место работы" соответственно. На рис.2 можно увидеть рабочее окно ERwin с построенной ERD-диаграммой. Верхняя строчка каждой сущности, отчёркнутая линией от остальной области, отводится для определения ключей. Но, поскольку к определению ключевых полей я ещё не приступил, эти поля остаются пустыми. В рабочем окне ERwin можно выделить несколько функциональных областей:

·Список основных меню программы;

·Чуть ниже находятся панели быстрого доступа к определённым функциональным возможностям программы;

·Непосредственно рабочая область для построения диаграмм;

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

Рис.2 ERD-диаграмма с атрибутами в рабочем окне ERwin

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

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

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

3.3 Нормализация данных, понятие нормальной формы

Итак, фраза "нормализация данных" означает приведение структуры БД к нормальной форме.

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

Процесс преобразования отношений базы данных (БД) к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в базе данных информации. Как отмечает К. Дейт, общее назначение процесса нормализации заключается в следующем:

·исключение некоторых типов избыточности;

·устранение некоторых аномалий обновления;

·разработка проекта базы данных, который является достаточно "качественным" представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;

·упрощение процедуры применения необходимых ограничений целостности.

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

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

3.4 Первая нормальная форма

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

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

В сущности "Работник" атрибут Name заменим тремя атрибутами Name, Family и Second, что соответствует имени, фамилии и отчеству работника. В изначальном наборе данных одно поле Name описывало имя, фамилию и отчество сотрудника, т.е. в одном поле было описано сразу три атрибута одной таблицы, а это противоречит правилу атомарности данных в каждой таблице, а, следовательно, противоречит требованиям первой нормальной формы.

По тому же принципу в сущности "Работник" атрибут Place заменим двумя атрибутами NativeLand и HomeTown, которые характеризуют родную страну и город, в котором родился работник (он же может быть выходцем из солнечного Еревана, например). Атрибут Address разложим на 4 атрибута City, Street, House и Apartment, что соответствует значениям населённого пункта, в котором живёт сотрудник, названию улицы, номеру дома и квартиры. Далее в сущности "Предыдущее место работы" атрибут WorkAdress заменим атрибутами WorkCity (город), WorkStreet (Улица), WorkBuildihg (номер дома), и Unit (номер блока\цеха\стороны дома), таким образом атомарно и точно описав адрес предыдущего места работы сотрудника университета.

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

Рис.3 первая нормальна форма

3.5 Вторая нормальная форма

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

3.5.1 Определение ключевых полей

Настало время поговорить о ключевых полях. Мощь реляционных баз данных, таких как Microsoft Access, опирается на их способность быстро найти и связать данные из разных таблиц при помощи запросов, форм и отчетов. Для этого каждая таблица должна содержать одно или несколько полей, однозначно определяющих каждую запись в таблице. Такие поля называют первичным ключом таблицы. Если для таблицы определен первичный ключ, то Microsoft Access предотвращает дублирование значений полей или ввод значений Null в эти поля. В Microsoft Access 2003 можно выделить три типа ключевых полей: простой ключ, составной ключ и счетчик. Если поле содержит уникальные значения, то его можно определить как ключевое или простой ключ. Примеры из нашей реальной жизни: идентификационный номер налогоплательщика, однозначно определяющий каждого жителя нашей страны, номер свидетельства пенсионного фонда, кадастровый номер земельного участка, реестровый номер строения, номер автомобиля - все это уникальные номера в пределах страны.

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

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

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

3.5.2 Установка связей между сущностями

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

Некоторые примеры взаимосвязей:

·команда включает много игроков,

·самолет перевозит много пассажиров,

·продавец продает много продуктов.

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

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

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

При проведении связи между двумя сущностями в дочерней сущности автоматически образуются внешние ключи (foreign key). Связь образует ссылку на атрибуты первичного ключа в дочерней сущности, и эти атрибуты образуют внешний ключ в дочерней сущности. Атрибуты внешнего ключа обозначаются символами (FK) после своего имени.

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

Для того чтобы установить связь сущности "Работник" с остальными, в рабочем окне ERwin на панели toolbox нужно выбрать связь типа identifying relationship (идентифицирующая связь) и кликнуть сначала на родительской сущности (в моём случае "работник"), а затем на дочерней (в моём случае их три - "Текущее место работы", "Предыдущее место работы" и "Образование").

На рис.4 видно, что первичный ключ, установленный для родительской сущности "работник", мигрировал во все дочерние сущности с пометкой (FK). Поскольку моя модель базы данных находится в первой нормальной форме и все поля всех её таблиц полностью и однозначно идентифицируются первичным внешним ключом, то можно сказать, что моя модель базы данных находится во второй нормальной форме.

Рис.4. Вторая нормальная форма

3.6 Третья нормальная форма

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

На данном этапе модель претерпевает самые значительные и кардинальные изменения в своей структуре. Если внимательно посмотреть на 4 образовавшиеся таблицы, то можно заметить, что многие неключевые атрибуты сущностей однозначно идентифицируют несколько других атрибутов. Так, например атрибут Passport (номер паспорта) сущности "работник" однозначно определяет атрибуты NativeLand (родная страна), HomeTown (родной город), PassportDate (дата выдачи паспорта), Birth (дата рождения) и Region (кем выдан паспорт). Данная ситуация является нарушением требований третьей нормальной формы, поэтому я создал ещё одну сущность с названием "паспортные данные" и вынес туда все вышеописанные атрибуты, связав при этом её с сущностью "работник" идентифицирующей связью. Поскольку помимо внешнего ключа, мигрировавшего к дочерней сущности от родительской, у каждой сущности нужно определить также и свой собственный ключ, который может быть как простым, так и составным, я сделал атрибут Passport ключевым для данной сущности.

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

Рассмотрев сущность "предыдущее место работы", можно увидеть, что связка атрибутов WorkBegin и Work однозначно определяет атрибуты WorkEnd, Reason, Penalty и Rewards, потому что если определённый сотрудник начал работать, скажем, менеджером по подбору персонала, он не может два раза в разное время окончить свою работу на этой должности. Отсюда следует, что если он окончил свою работу на определённой должности, то причина увольнения может быть указана только один раз, как и сведения о взысканиях и награждениях. Логично будет в этой ситуации создать ещё одну сущность с названием "опыт работы" и вынести туда все вышеописанные атрибуты, установив определяющие атрибуты ключевыми и создав зависимую связь с сущностью "работник".

Данные распределены по таблицам и структура модели стала более логически упорядоченной и менее загруженной. Но при внимательном рассмотрении сущности "Образование" можно заметить ещё одну транзитивную зависимость атрибутов DegreeYes и Degree от внешнего ключа модели. Избавиться от неё можно созданием ещё одной сущности "Научные достижения" и вынесением туда атрибутов Degree, Rank и DegreeYes в качестве ключа. Но на этом останавливаться пока рано, поскольку вариантов записи учёного звания и учёной степени может быть несколько, а это недопустимо по правилам первой нормальной формы. Для того чтобы избежать конфликтов и повторений, я создал ещё две таблицы-справочника под названием "учёная степень" и "учёное звание". Они будут содержать всего по 2 поля - номер звания или степени и само их название. Отличие этих сущностей от остальных в том, что они связаны только с сущностью "Научные достижения" неидентифицирующей связью (объект non-identifying relationship на панели toolbox). Это означает, что эти сущности сами являются родительскими и их ключевые атрибуты мигрируют в дочернюю в качестве внешних ключей. В таблице "Научные достижения" эти поля будут содержать просто ссылку на номер учёного звания или учёной степени, название которых хранится в одноимённых таблицах, что позволит избежать недопустимых значений в этих полях.

Осталась только одно несоответствие правилам нормализации - в сущности "предыдущее место работы" атрибут WorkPhone может принимать несколько значений, ведь в организации, в которой раньше работал сотрудник, может быть несколько рабочих телефонов, а это противоречит даже правилам первой нормальной формы. Необходимо создать отдельную сущность "рабочий телефон" и связать её с сущностью "предыдущее место работы" идентифицирующей связью, что подразумевает миграцию ключей родительской сущности в дочернюю. После определения ключевых атрибутов у остальных сущностей можно сказать, что модель базы данных полностью удовлетворяет требованиям третье нормальной формы и находится в ней (рис.5).

Рис.5 третья нормальная форма

3.7 Проверка адекватности логической модели

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

·Работник работает на месте работы.

·Работник имеет опыт работы.

·Работник имеет научные достижения.

·Учёное звание присвоено за научные достижения.

·На предыдущем месте работы имеется рабочий телефон

·Учёная степень присвоена за научные достижения и др.

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

Рис.6 пример связей с проверочными глаголами

3.8 Установление параметров связей между сущностями

3.8.1 Определение типа и мощности связей

Связь является логическим соотношением между сущностями. Связь имеет имя, мощность, тип.

Имя связи (Verb Phrase) - фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи один-ко-многим достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child).

Мощность связи (Cardinality) - служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.

Различают четыре типа мощности:

общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности (не помечается каким-либо символом);

символом P помечается случай, когда одному

P экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);

символом Z помечается случай, когда одному

Z экземпляру родительской сущности соответствуют 0 или

экземпляр дочерней сущности (исключены множественные значения);

цифрой помечается случай, когда одному экземпляру

N родительской сущности соответствует заранее заданное

число экземпляров дочерней сущности.

Различают два типа связей: идентифицирующая и неидентифицирующая.

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

Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. В дочерней сущности новые атрибуты помечаются как внешние ключи - (FK).

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

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

Для неидентифицирующей связи можно указать обязательность (Nulls). В случае обязательной связи (No Nulls) при генерации схемы БД атрибут внешнего ключа получит признак NOT NULL, несмотря на то, что внешний ключ не войдет в состав первичного ключа дочерней сущности. В случае необязательной связи (Nulls Allowed) внешний ключ может принимать значение NULL. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности.

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

Для того чтобы указать определённый набор настоек связи, нужно выделить связь, щелкнув по ней указателем мыши. Затем нажать правую кнопку мыши и в контекстном меню выбрать пункт Relationship Properties (редактор связей).

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

Кроме того, диалоговое окно редактора связей содержит следующие закладки:

?General (общие свойства). Здесь задаются общие свойства связи - имя, тип и мощность связи.

?Definition (определение). На этой странице вводится определение связи, облегчающее восприятие модели.

?Rolename (Имя роли) - вводятся функциональные имена (для мигрирующих атрибутов).

?RI Actions (Установки ссылочной целостности) - задаются правила ссылочной целостности.

Из настроек связей я на данном этапе проектирования изменял только имя связи, тип и мощность, их можно увидеть на рис.7

Преобладают в моей модели связи с мощностью "One or More", поскольку в большинстве случаев у работника может быть один или больше экземпляров сущности. Так, сущность "место работы" связана с сущностью "работник" связью "One or More", потому что широко распространена практика работы одного преподавателя в нескольких вузах одновременно. Связь такого же типа связывает сущности "Работник" и "Жильё", поскольку у одного человека, теоретически, может быть несколько квартир. Так как высших образования у человека может быть так же несколько, к сущности "Образование" так же проведена связь "One or More". Сущности "Предыдущее место работы" связана с сущностью "Рабочий телефон" этим же типом связи, так как вероятность того что на предыдущем месте работы сотрудника вообще не будет рабочего телефона крайне мала. Сущность "Опыт работы" связана с сущностью "работник" связью мощностью "Zero, One or More", поскольку опыта работы у сотрудника может как не быть вовсе, так и быть более чем на одном предприятии. Учёные степени или звания могут либо быть у работника, либо отсутствовать, поэтому для сущности "научные достижения" установлены связи мощностью "Zero or One". Паспорт у одного человека может быть только один, поэтому у связи сущностей "Работник" и "Паспортные данные" установлена мощность связей в фиксированном выражении 1 экземпляра.

Рис.7 типы и мощность связей

3.8.2 Задание правил декларативной ссылочной целостности

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

Существуют следующие виды действий или правил, определяемых в логической модели:

·RESTRICT - запрет удаления, вставки или изменения экземпляра сущности.

·CASCADE - при удалении экземпляра родительской сущности удаление всех экземпляров дочерней сущности, ссылающихся на удаляемый родительский экземпляр.

·SET NULL - при удалении экземпляра родительской сущности атрибутам внешнего ключа всех экземпляров дочерней сущности присваивается значение NULL.

·SET DEFAULT - то же самое, что и в предыдущем случае, только вместо значения NULL присваивается значение по умолчанию.

·NONE - никаких действий не предпринимается.

Эти правила задаются на вставку, удаление и изменение экземпляра как родительской, так и дочерней сущности. Таким образом, каждая связь должна обладать набором из шести правил, которые вводятся в поля, объединенные общим заголовком "RI Actions". При добавлении связи в диаграмму ERwin по умолчанию устанавливает для нее набор правил, которые можно редактировать. Для вызова редактора связей необходимо выделить связь "паспорт" между сущностями "Работник" и "Паспортные данные", щелкнув по ней указателем мыши. Затем нужно нажать правую кнопку мыши и в контекстном меню выбрать пункт Relationship Properties (редактор связей). В окне редактора связей Relationship я перехожу на вкладку RI Actions. Здесь можно ознакомиться с правилами ссылочной целостности для связи "Работник - Паспортные данные", присвоенными по умолчанию (рис.8). Данные установки запрещают вставку и изменение экземпляра дочерней сущности, а также удаление и изменение родительской сущности. Это означает, что не допускается удаление или изменение работника, если в базе данных имеются записи о его паспортных данных, а также ввод паспортных данных без указания работника или со ссылкой на несуществующего работника. Тем самым мы выполнили условие, по которому запись о паспортных данных может существовать только для конкретного сотрудника университета.

Рис.8 Установки ссылочной целостности для связи "паспорт"

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

3.9 Установление альтернативных ключей, инверсных входов и определение типов атрибутов

Потенциальный ключ, не ставший первичным, называется альтернативным ключом (Alternate Key). ERWin позволяет выделить атрибуты альтернативных ключей, и по умолчанию в дальнейшем при генерации схемы БД по этим атрибутам будет генерироваться уникальный индекс. При создании альтернативного ключа на диаграмме рядом с атрибутом появляются символы (АК).

Атрибуты, участвующие в неуникальных индексах, называются инверсионными входами (Inversion Entries). Инверсионные входы - это атрибут или группа атрибутов, которые не определяют экземпляр уникальным образом, но часто используются для обращения к экземплярам сущности. ERWin генерирует неуникальный индекс для каждого инверсионного входа.

В данном примере я устанавливаю альтернативные ключи и инверсные входы для сущности "Предыдущее место работы". Для установления альтернативного ключа или инверсного входа необходимо вызвать редактор ключевых групп Key Groups, щелкнув правой кнопкой мыши по сущности "Предыдущее место работы и выбрав из контекстного меню пункт Key Groups. Редактор ключевых групп также можно вызвать через главное меню: Model | Key Groups.

Редактор ключевых групп содержит элементы управления:- поле с выпадающим списком, в котором следует выбрать сущность для редактирования.

Окно с перечнем ключевых групп. Каждая группа представлена отдельной строкой, включающей в себя имя (Key Group), тип (Type) и определение (Definition).

Кроме того, диалоговое окно редактора ключевых групп содержит следующие закладки:

?Members (члены). Задаются члены ключевых групп и их порядок следования в группе.

?General (общие установки). Переключатели, позволяющие задавать тип ключевой группы. Для первичного и внешнего ключа эти группы недоступны.

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

?Note (примечание). Примечание к выбранной группе.

?UDP (пользовательские свойства).

Для создания нового альтернативного ключа необходимо нажать кнопку New

?Далее в окне New Key Group в поле Key Group ввести имя ключевой группы - Предыдущее место работы. В поле Index выводится генерируемое программой Erwin имя индекса. Его я оставляю без изменений.

?Переключатель Key Group Type задает тип создаваемого ключа. Это может быть альтернативный ключ (Alternate Key) или инверсный вход (Inversion Entry). В данном случае я выбрал сначала Alternate Key и нажал ОК. Вновь введенный альтернативный ключ появился в перечне ключей.

?Перехожу на закладку Members. Новый ключ пока не содержит никаких атрибутов, поэтому правый список Key Group Members (члены ключевой группы) пуст. Выбираю в левом списке атрибуты WorkStreet, WorkBuilding и Unit, и перемещаю их в правый список при помощи кнопки со стрелкой (рис.9).

Рис.9 редактор ключевых групп

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

Создание инверсного входа проходит по точно такому же алгоритму, и единственным отличием является выбор пункта Inversion Entry после нажатия кнопки New в окне редактора ключевых групп, а не Alternate Key. В моём примере поля для определения инверсного входа так же отличаются от полей альтернативного ключа, но, тем не менее, возможны случаи, когда один и тот же атрибут входит как в состав альтернативного ключа или является им, так и в состав инверсного входа. В моём случае в качестве инверсного входа я указал атрибут WorkPlace, поскольку название предприятия может часто использоваться в запросах на выборку определённых данных.

Для определения типов данных необходимо выделить любую сущность, щёлкнув по ней, а затем вызвать пункт меню Model | Attributes. То же самое можно выполнить, выбрав пункт Attributes контекстного меню. При этом на экране появится окно редактора атрибутов Attributes.

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

В группе Domain находится список доменов, представляющих основные типы данных, используемые в СУБД: строковый (string), числовой (number), время (datetime), двоичный (blob). Также, в случае, когда определение домена вызывает затруднения, можно не выбирать конкретный домен, а оставить значение default. Для атрибута WorkBegin, например, я указал домен даты - datetime, а при определении домена для атрибута penalty-строковый домен (string). Аналогичным образом я определил типы доменов для каждого атрибута. В результате окно редактора атрибутов будет выглядеть так, как показано на рис.10.

Рис.10 Атрибуты сущности Penalty

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

Итак, после указания всех альтернативных ключей, инверсных входов, и определения доменных типов данных для всех атрибутов, этап логического проектирования модели данных заканчивается. На рис.11 можно увидеть логическую модель данных в полностью завершённом виде. Символами (AK) обозначаются альтернативные ключи, обозначение (IE) соответствует инверсным входам, а доменные типы данных указаны в каждой сущности справа от каждого атрибута. Следующий шаг - создание физической модели данных.

Рис.11 окончательный вид логической модели данных

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

4.1 Переход к физическому уровню модели

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

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

Для трансформации логической модели в физическую необходимо выбрать меню Tools | Derive New Model. В открывшемся диалоговом окне (рис.12) выбрать тип модели, в которую необходимо произвести трансформацию. ERwin может создать как чисто физическую модель данных, для работы с моделью только на физическом уровне, так и комбинированную физико-логическую модель. Она удобна тем, что даёт возможность в любой момент времени переключаться между видом модели на физическом и логическом уровне проектирования. Внизу диалогового окна необходимо выбрать сервер (СУБД), на который в будущем будет перенесена база данных.

В блоке New Model Type я выбрал пункт Logical/Physical, поскольку существует вероятность того, что в процессе разработки модели БД на физическом уровне мне придётся возвращаться на логический и обратно, так как некоторые функции редактирования модели ERwin делает доступными либо только на логическом уровне, либо, наоборот, только на физическом.

В блоке Target Database программа предлагает выбрать целевую СУБД, в которую потом будет переносится созданная структура. В выпадающих списках я выбрал пункт Access версии 2000/2002/2003.

Рис.12 окно трансформации логической модели данных в физическую

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

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

4.2 Денормализация данных

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

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

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

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

За счёт такого перепроектирования операция соединения при выборке становится ненужной и запросы выборки, которые ранее требовали соединения, работают быстрее.

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

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

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

·Сущности, атрибуты, группы ключей и домены можно создавать только на логическом уровне модели.

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

·Таблицы, столбцы, индексы и домены можно создавать только на физическом уровне.

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

·Разрешение связей "многие-ко-многим". При разрешении этих связей в логической модели ERWin добавляет ассоциированные сущности и позволяет добавить в них атрибуты. При разрешении связей в логической модели автоматически разрешаются связи и в физической модели.

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

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

В такой ситуации может помочь:

·Денормализация путем сокращения количества таблиц. Лучше объединять в одну несколько таблиц, имеющих небольшой размер, содержащих редко изменяемую (как часто говорят, условно-постоянную, или нормативно-справочную) информацию, причем информацию, по смыслу тесно связанную между собой.

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

·Денормализация путём ввода дополнительного поля в одну из таблиц. При этом появляется избыточность данных, требуются дополнительные действия для сохранения целостности БД.

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

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

Для решения данной проблемы нужно создать ещё одну сущность "День рождения", связав его идентифицирующей связью с ключевой сущностью "Работник". После создания сущности я внёс в неё атрибуты BirthDay, BirthMounth и BirthYear, описывающие день, месяц и год рождения соответственно.

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

Рис.13 Денормализованная физическая модель базы данных

4.3 Корректировка типов и размеров полей

На этапе логического проектирования я указывал только типы доменов для каждого атрибута. Но в ERwin поддерживается ещё и точное определение типов полей для конкретной выбранной СУБД. Сейчас в полученной физической модели необходимо скорректировать типы и размеры полей для заданной СУБД Access в соответствии с табл.5.

Таблица 5

Типы данных и размеры колонок таблиц физической модели

ТаблицаКолонкаТип данныхОпыт работыWorkBeginDate/TimeWorkText (20) WorkEndDate/TimeReasonText (30) PenaltyMemoRewardsMemoНаучные достиженияDegreeYesYes\NoRankIntegerDegreeIntegerУчёная степеньDegreeNameText (40) Учёное званиеRankNameText (20) ОбразованиеEducationText (40) YearIntegerSpecialityText (30) Место работыDepartmentText (40) InstituteText (40) PostText (20) CommentMemoЖильёPhoneText (15) CityText (20) StreetText (20) HouseIntegerApartmentIntegerРаботникPersonIDIntegerNameText (15) FamilyText (20) SecondText (20) PictureOLE ObjectПредыдущее место работыWorkPlaceText (20) WorkCityText (20) UnitText (5) WorkBuildingIntegerWorkStreetText (20) Рабочий телефонWorkPhoneText (15) День рожденияBirthDayIntegerBirthMounthText (10) BirthYearIntegerПаспортные данныеPassportLong IntegerBirthDate/TimeNativeLandText (15) HomeTownText (20) PassportDateDate/timeRegionText (40)

• Для этого необходимо вызвать редактор колонок Columns через пункт главного меню Model | Column, либо через контекстное меню.
• Редактируемая таблица выбирается в списке Table. Для каждой колонки таблицы на закладке Access определяется тип данных согласно табл.5, выбрав в поле Access Datatype из списка нужное значение.
• Кроме того, здесь задается опция NULL (группа Null Option), которая определяет допустимость пустых значений поля.

Всего в модели фигурируют 7 различных типов данных:

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

·Integer - числовой тип. Допускает использование чисел различных форматов.

·Memo - числовое поле, допускающее набор текста длиной до 65000 символов.

·OLE Object - поле, позволяющие вставлять рисунки, звуки и данные других типов.

·Date/Time - типа дата\время.

·Long Integer - числовой тип данных, позволяет использовать числовые значения, слишком длинные для типа Integer.

·Yes/No - логический тип, допускает только значения поля "Да" или "Нет".

После выполнения всех описанных выше действий, физическая модель данных приняла свой завершённый вид. На рис.14 представлена полностью готовая к переносу в СУБД модель моей базы данных. На этом работа с программой ERwin завершена. Следующее действие - проверка полученной модели данных с помощью программного решения CA Erwin Data Model Validator, позволяющего проанализировать работоспособность и адекватность построенной модели данных и, при необходимости, внести определённые коррективы в её структуру.

Рис.14 готовая к переносу в СУБД физическая модель данных

4.4 Проверка структурной целостности модели данных

Прежде чем переносить спроектированную модель данных в систему управления базами данных, будет нелишним проверить полученную схему на предмет логической целостности и отсутствия ошибок проектирования. Для этих целей я использовал программу CA ERwin Data Model Validator. Предлагаемые в ней средства диагностики и проверки, основанные на правилах реляционного моделирования, помогут убедиться в структурной целостности моделей данных CA ERwin Data Modeler или кода SQL/DDL. Все несоответствия в проекте будут выявлены немедленно, после чего программа предложит рекомендации по устранению неисправностей и автоматически сгенерирует сценарии для реализации выбранных исправлений.

Продукт CA ERwin Data Model Validator позволяет анализировать структуры данных, ключи, индексы, столбцы и отношения. Кроме того, решение поможет отобразить в графическом виде структуру всей базы данных, включая столбцы с перекрестными ссылками и списки отношений.

Самостоятельная проверка и подтверждение моделей данных занимает достаточно много времени. Решение CA ERwin Data Model Validator предлагает функцию "Show Me" для локализации проблем, возникающих при проектировании сложных моделей баз данных. Таким образом, разработчикам не придется вручную перебирать тысячи строк программного кода. Кроме того, предоставляемая в составе продукта функция "Teach Me" позволит без труда предугадать эффект от внесенных в проект изменений.

Для проверки схемы данных необходимо сохранить ERD-диаграмму, построенную в CA ERwin Data Modeler, и затем выбрать пункт меню Tools | CA ERwin Data Model Validator. В открывшемся окне CA ERwin Data Model Validator, нужно выбрать пункт File | New, и в открывшемся диалоговом окне прописать путь до сохранённой ранее ERD-диаграммы.

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

Рис.15 Предварительные результаты проверки ERwin Validator

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

Проведя диагностику моей модели, ERwin Validator выдал результаты в виде иерархического списка ошибок, предупреждений, предостережений и советов по увеличению производительности базы данных. На рис.16 видно, что в моей модели данных отсутствуют серьёзные ошибки (several errors) и другие ошибки (errors). Предостережений (cautions) так же нет. Программа даёт 9 рекомендаций по увеличению производительности БД, но выполнить их не представляется возможным, поскольку все они имеют отношение к слишком большому, по мнению ERwin Validator, количеству связей таблицы "Работник" с остальными.

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

Рис.16 Результаты анализа модели данных

Итак, опираясь на данные ERwin Validator, можно сказать, что моя модель данных адекватна и отвечает всем требования логической целостности данных. Теперь моя модель БД полностью готова к переносу на выбранную ранее СУБД.

4.5 Генерация системного каталога базы данных

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

• В программе Erwin выполнить команду Tools | Forward Engineer/Schema Generation.
• В диалоговом окне Access Schema Generation на закладке Option задать опции генерации объектов модели, выбирая в левом списке объект, а в правом - соответствующие ему опции. Щелкнуть по кнопке Generate.
• В диалоговом окне Access Connection установить связь с созданной базой данных, заполнив все предложенные поля.
• В случае установления соединения будет выполняться SQL-скрипт. Если в процессе генерации возникают ошибки, то она прекращается, открывается окно с сообщениями об ошибках.

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

Рис.17 Сгенерированная схема данных в Microsoft Access 2003

4.6 Задание правил валидации

4.6.1 Общее понятие правил валидации

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

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

Условие на значение поля задает проверку введенных значений при выходе пользователя из поля. Например, примером условия на значение для числового поля может служить выражение ">=10 And <=100", разрешающее ввод значений только от 10 до 100.

Условие на значение записи применяется при сохранении всей записи. В отличие от условий на значение поля, в условиях на значение записи допускаются ссылки на другие поля. Это позволяет использовать такие условия для сравнения значений, введенных в разные поля таблицы. Например, в качестве условия на значение для таблицы "Заказы" можно указать выражение: " [КонечнаяДата] <= [ДатаЗаказа] +30". Это гарантирует, что дата, введенная в поле "КонечнаяДата", будет отличаться от даты в поле "ДатаЗаказа" не более чем на 30 дней.

Если условие на значение для поля или записи нарушается, Access выводит сообщение, содержащее сведения, как правильно вводить данные.

В моём примере встречаются 2 типа условий на значение: задание правил проверки вводимых значений, и задание списка допустимых значений.

4.6.2 Задание правил проверки вводимых значений

Первое поля, для которого я установил правила проверки - поле Birth в таблице "Паспортные данные". В это поле вводится дата рождения сотрудника. Для того чтобы ввести условие на значение для этого поля, необходимо выделить в списке таблиц таблицу "Паспортные данные" и выбрать режим конструктора для редактирования свойств таблицы. В конструкторе нужно выбрать поле Birth и внизу, во вкладке Общие, ввести в строчку Условие на значение правило проверки значений таблицы. Для данного поля будет достаточно внесения временного диапазона более-менее разумной протяжённостью. Я задал условие проверки таким образом, чтобы в данное поле можно было внести дату, которая находилась бы во временном диапазоне между 01.01.1912, поскольку родившемуся в 1912 человеку сейчас было бы 100 лет, что не вписывается в разумные пределы проверки возраста, и настоящим временем. Согласно синтаксису языка SQL для версии Microsoft Access 2003, все даты записываются между двумя символами "#". Таким образом Access распознаёт, что указанный набор цифр является датой. Настоящее время же считывается с системной даты на компьютере, на котором база данных открыта в каждый момент времени. Для того чтобы дата считывалась с системных показателей используется оператор Date (). В итоговом виде правило для проверки даты рождения выглядит так: >=#01.01.1912# And <Date (). Одной строчкой ниже расположена строка "сведения об ошибке". Сюда записывается небольшое информационное сообщение для пользователя базы данных, который допустил ошибку при работе и ввёл значение, не соответствующее допустимому. В данном случае пользователь, который ввёл дату не из описанного выше диапазона, увидит следующее сообщение: "введите дату между 01.01.1912г. и сегодняшней".

Аналогичным образом я установил правило проверки для поля Year в таблице "Образование". В данное поле вводится год окончания работником ВУЗа. Но, поскольку на работу в преподавательский состав университета не могут взять человека, который ещё сам не получил высшего образования, или получившего его только что, необходимо отмести возможность ввода года окончания обучения более позднего, чем текущий. Для этого Я прибегнул к помощи оператора Year, который возвращает значение типа Variant (Integer) - целое число, обозначающее год. А для того чтобы оператор Year возвращал год из значения системной даты я опять же применил оператор Date. В итоге получилось следующее выражение условия на значение: <Year (Date ()). В описании ошибки было указано "введите более раннюю дату".

Следующим правилом я задал проверку даты начала трудовой деятельности. Полем WorkBegin в таблице "Опыт работы". Особенностью этого условия на значение является то, что оно задаётся для записи, а не для поля, поскольку согласно механизму проверки и здравому смыслу, дата начала трудовой деятельности должна быть раньше, чем дата её окончания, а ссылки на разные колонки одной таблицы допускаются только при задании условия на значения для записи. Для задания правила проверки для всей записи необходимо щёлкнуть правой кнопкой мыши на любом пустом участке рабочей области конструктора и в выпадающем меню выбрать пункт Свойства. Далее в строке Условие на значение я ввёл выражение, которое не допускает ввод даты окончания рабочей деятельности, если дата более ранняя, чем введённая в поле WorkBegin (начало рабочей деятельности). Ведь невозможно закончить рабочую деятельность на определённой должности раньше, чем начать её. Итоговое выражение выглядит так: [WorkBegin] < [WorkEnd]. В квадратных скобках, согласно синтаксису SQL, заключаются названия полей одной таблицы

4.6.3 Создание списка допустимых значений

Последним правилом валидации я установил список допустимых значений. Этот метод проверки несколько отличается от выражения для проверки вводимого значения. При создании списка допустимых значений в поле для ввода условия на значение вводится оператор In (), в котором перечисляются все значения через знак ";". Такой список я создал для поля BirthMounth, содержащий информацию о месяце рождения в таблице "День рождения". Поскольку месяцев всего 12, то для создания списка достаточно перечислить их названия. В сообщении об ошибке я вписал просьбу ввести словесное обозначение месяца с большой буквы.

5. Проектирование на уровне MS Access 2003

5.1 создание запросов

После заполнения базы данных осталось сделать запросы, отчёты и создать формы для ввода и редактирования данных. В моём примере я начал с запросов. Все запросы и отчёты я создавал в режиме конструктора, для этого в меню запросов в верхней части окна достаточно нажать кнопку "создать" и в следующем окне выбрать конструктор как инструмент создания. Изначально в моей базе данных появилось 4 запроса:

·"Список работников" - отражает полный список сотрудников, которые находятся в базе данных.

·"Сотрудники с учёной степенью" - содержит перечень сотрудников из базы, имеющих учёную степень, а так же показывает наименование учёной степени для каждого сотрудника.

·"Сотрудники с учёным званием" - по содержанию аналогичен предыдущему запросу, только показывает не учёные степени сотрудников, а их звания.

·"Место обучения и предыдущее место работы" - содержит сводную информацию о месте обучения и предыдущем место работы каждого сотрудника в базе данных.

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

Например, для создания запроса "Сотрудники с учёной степенью", я использовал поля из таблиц "Работник", "Научные достижения" и "Учёная степень". Из таблицы "Работник" Я использовал поля Name (Имя), Family (Фамилия) и Second (Отчество). Они служат для идентификации каждого сотрудника в удобной для восприятия форме в виде имени, фамилии и отчества (рис.18). Из таблицы "Научные достижения" используется поле DegreeYes, которое и позволяет отобрать именно тех сотрудников ВУЗа, которые имеют учёную степень.

Рис.18 Построение запроса

Для того чтобы запрос корректно работал, нужно чтобы в него попадали только те записи поля DegreeYes, значение которых соответствует истине, поэтому в условии отбора я написал слово "Истина", и снял галочку в пункте "Вывод на экран". Целевому пользователю совсем не обязательно видеть поле, в котором в каждой записи написано слово "да". И последнее поле, которое будет использовано в запросе - это поле Degree, содержащее в себе информацию о названии учёной степени, присвоенной сотруднику.

Подобным образом создавались все запросы моего программного комплекса, поэтому описывать создание остальных запросов не имеет смысла.

5.2 Создание отчётов

Создание отчётов происходит в два этапа. Сначала необходимо создать базовый запрос или таблицу, и только потом на их основе редактировать отчёт. В качестве примера можно взять отчёт "Перечень доцентов по кафедрам". Для начала я создал одноимённый запрос, в который вошли, соответственно, поля, содержащие информацию об имени, фамилии, отчестве сотрудника, а так же кафедре, на которой он работает и его учёном звании. Поскольку название запроса говорит само за себя, то необязательно отображать в отчёте поле с информацией о том, что данный сотрудник является доцентом, это и так очевидно. Но, тем не менее, это поле необходимо добавить в запрос для отбора данных, поэтому я сделал его невидимым, сняв галочку "Вывод на экран" (Рис. 19).

Рис. 19 Создание базового запроса для отчёта

Итак, базовый запрос готов, теперь достаточно просто создать на его основе в режиме конструктора отчёт, перенеся на область данных отчёта все поля запроса и отредактировав их местоположение относительно друг друга. При построении отчёта необходимо выбрать, на основе какого запроса или таблицы будет сформирован отчёт. Для построения отчёта в моём случае подходит только запрос, поскольку его можно сформировать из полей разных таблиц (Рис. 20).

Рис.20 создание отчёта на основе выбранного запроса.

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

·Список сотрудников, имеющих благодарности;

·Список сотрудников, имеющих взыскания;

·Перечень всех сотрудников по кафедрам;

·Перечень кандидатов наук по кафедрам;

·Перечень доцентов по кафедрам;

·Дни рождения сотрудников.

6. Разработка приложения

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

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

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

Вся работа с приложением проходит через кнопочные формы, что упрощает работу с данными и делает её более удобной и комфортной.

6.1 Разработка структуры приложения

6.1.1 Разработка режима пользователя

В своей работе я начал разработку приложения с режима пользователя. Поскольку для пользователя важно сделать максимально удобную организацию полей базы, то реализовать это я решил с помощью одной материнской и нескольких подчинённых форм. На первой форме, названной "Сотрудник", находится вся информация о человеке, связанная с его рабочей деятельностью в ВУЗе. Фамилия, имя, отчество, научные достижения, кафедра, должность, поощрения и взыскания. Так же на этой форме находится фотография сотрудника. С этой же формы, с помощью кнопок можно перейти на любую из 3 подчинённых форм, содержащих информацию о паспортных данных сотрудника, его домашнем адресе и опыте работы. К самим формам применены средства визуализации фона и шрифта. Также на форме находятся кнопки навигации по записям, поиск записи в базе и возможность перехода на главную кнопочную форму. Отсюда же пользователь имеет доступ на формы, содержащие кнопки перехода к отчётам и запросам моей БД (Рис.21).

Рис.21 Вид основной формы для работы в режиме пользователя

Помимо форм, предоставляющих информацию о каждом человеке в моём программном комплексе, я создал ещё две формы для режима пользователя. На одной из них располагаются кнопки перехода к каждому созданному запросу (Рис.22).

Рис.22 Форма перехода к запросам

На другой - кнопки запуска отчётов, а так же кнопки для их распечатки и вывода в отдельный текстовый файл, поскольку пользователю, работающему с этими данными, может потребоваться вывести отчёт на печать или пересохранить отдельно в электронном виде (Рис.23).

Рис.23 Форма перехода к отчётам

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

6.1.2 Разработка режима администратора

Режим администратора должен иметь вид, более удобный для внесения, изменения и удаления записей из БД. Его структура в моей работе очень отличается от структуры режима пользователя. Нажатие на кнопку "База данных" отсылает к другой форме, на которой посредством кнопок реализованы переходы к формам, по набору полей практически идентичным каждой таблице в БД. Единственное изменение - в таблицах у меня повторяется только поле PersonID, которое является ключевым, а в формах я так же добавил поля ФИО, чтобы администратору было проще идентифицировать людей, данные на которых он редактирует (Рис.24).

Рис.24 Основная форма для работы в режиме администратора

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

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

6.2 Создание главной кнопочной формы

После разработки режимов пользователя и администратора можно приступать к созданию главной кнопочной формы. На ней симметрично друг другу расположены кнопки доступа к режиму пользователя и администратора, запросам и отчётам, а так же кнопка выхода из программы (Рис.25).

Рис.25 Главная форма программного комплекса

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

Рис.26 Настройка параметров запуска для главной формы

После того как главная кнопочная форма создана, можно считать завершённой процесс разработки моего программного комплекса. На этом процесс разработки завершён.

Заключение

В ходе выполнения курсовой работы были рассмотрены основные методы работы с Microsoft Access 2003, базовые инструменты и приёмы работы с такими CASE-средствами как CA ERwin Data Modeler и CA ERwin Data Model Validator.Access 2003 - универсальный набор программных средств, которые обеспечивают широкие возможности для профессиональных разработчиков и вместе с тем могут быть легко освоены новичками. Любой пользователь может создавать и применять универсальные решения для баз данных, значительно упрощающие организацию, совместное использование данных и доступ к ним.Erwin Data Modeler: CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования таких аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания.ERwin Data Modeler (ERwin) предназначен для всех компаний, разрабатывающих и использующих базы данных, для администраторов баз данных, системных аналитиков, проектировщиков баз данных, разработчиков, руководителей проектов. AllFusion ERwin Data Modeler позволяет управлять данными в процессе корпоративных изменений, а также в условиях стремительно изменяющихся технологий.ERwin Data Modeler (ERwin) позволяет наглядно отображать сложные структуры данных. Удобная в использовании графическая среда AllFusion ERwin Data Modeler упрощает разработку базы данных и автоматизирует множество трудоемких задач, уменьшая сроки создания высококачественных и высокопроизводительных транзакционных баз данных и хранилищ данных. Данное решение улучшает коммуникацию в вашей организации, обеспечивая совместную работу администраторов и разработчиков баз данных, многократное использование модели, а также наглядное представление комплексных активов данных в удобном для понимания и обслуживания формате.ERwin Data Model Validator - cредства диагностики и проверки, используются для проверки структурной целостности моделей данных CA ERwin Data Modeler или кода SQL/DDL путем применения правил реляционной технологии. CA ERwin Data Model Validator помогает обнаруживать дефекты проектирования, выдает рекомендации корректирующих действий и автоматически генерирует сценарии для реализации выбранных корректировок.ERwin Data Model Validator анализирует структуры данных, ключи, индексы, поля столбцов и отношения на предмет нарушений правил проектирования реляционных баз данных. CA ERwin Data Model Validator выдает детализированные диагностические отчеты, помогающие увеличивать продуктивность за счет ускорения процесса анализа.

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

Список источников

1.Трипутина, В.В. Проектирование баз данных с помощью Case-средства ErWin. Методические указания к выполнению лабораторных работ: учебное пособие / В.В. Трипутина. - Иркутск: Издательство Иркутского государственного технического университета.

2.Кренке, Д. Теория и практика построения баз данных / Д. Кренке. - СПб: ПИТЕР, 2005 г.

.Дорофеев, A.С. Методические указания к выполнению курсового проекта по дисциплинам базы данных, управление данными: учебное пособие / А.С. Дорофеев. - Иркутск: Издательство Иркутского государственного технического университета, 2007 г.

.Г.А. Разработка реального приложения в среде клиент-сервер.

.Учебное пособие. - Хабаровск: Изд-во ДВГУПС, 2005. - 204 с.: ил.

.Журнал "Открытые системы" №2 2009.

.Гончаров А.Ю. ACCESS 2003. Самоучитель с примерами. Учебное пособие. - М: Кудиц-Образ, 2004 - 270с.

.Гурвиц Г.А. Разработка реального приложения в среде клиент-сервер. Учебное пособие. - Хабаровск: Изд-во ДВГУПС, 2005. - 204

9.<#"center">Приложение

Набор исходных данных для разработки программного обеспечения

№ПолеТипРазмерОписание1PersonIDЧисловой5Регистрационный номер сотрудника2NameТекстовый40ФИО сотрудника3DepartmentТекстовый40Название кафедры, на которой работает4InstituteТекстовый40Название института (департамента) 5BirthДатаАвтоДата рождения сотрудника6PlaceТекстовый20Место рождения7AddressТекстовый60Домашний адрес сотрудника8PhoneТекстовый15Домашний телефон сотрудника9EducationТекстовый40Оконченный ВУЗ10YearЧисловой4Год окончания ВУЗа11SpecialityТекстовый30Специальность сотрудника12PictureПоле OLEАвтоФотография сотрудника13DegreeYesЛогический1Ученая степень (есть/нет) 14DegreeЧисловой1Ученая степень сотрудника15RankЧисловой1Ученое звание сотрудника16PostТекстовый20Занимаемая должность17CommentПоле MemoАвтоПримечания18PassportТекстовый20Номер паспорта19PassportDateДатаАвтоДата выдачи паспорта20RegionТекстовый40Кем выдан паспорт21WorkBeginДатаАвтоДата начала трудовой деятельности22WorkEndДатаАвтоДата окончания трудовой деятельности23WorkТекстовый20В качестве кого работал24WorkPlaceТекстовый20Название предприятия25WorkAddressТекстовый60Адрес предприятия26WorkPhoneТекстовый15Телефон предприятия27ReasonТекстовый30Причина увольнения28PenaltyПоле MemoАвтоСведения о взысканиях29RewardsПоле MemoАвтоСведения о награждениях

Содержание Введение 1. Этапы проектирования базы данных 2. Концептуальное проектирование 2.1 Анализ предметной области 2.2 Построение семанти

Больше работ по теме: