Разработка информационной системы на MS Access

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

       СУБД — система управления базами данных (DBMS — DataBase Management System). СУБД представляет полный контроль над процессом определения данных, их обработкой и совместным использованием. Под системой понимается программа, которая не только позволяет хранить большие массивы данных , но и обрабатывать их, представляя в удобном для пользователя виде. 

1.2 Этапы развития базы данных 

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

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

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

       Совокупность  ступеней развития базы данных от возникновения  идеи до полного завершения проекта принято разделять на этапы:

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

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

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

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

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

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

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

1.3 Иерархическая модель  

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

       Узел  – информационная модель элемента, находящегося на данном уровне иерархии.

       Свойства  иерархической модели данных:

       - Несколько узлов низшего уровня связано только с одним узлом высшего уровня.

       - Иерархическое дерево имеет только одну вершину (корень), не подчиненную никакой другой вершине.

       - Каждый узел имеет свое имя (идентификатор).

       - Существует только один путь от корневой записи к более частной записи данных. 

1.4 Проектирование базы данных 

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

       Первым  шагом в проектировании базы данных является получение формального  описания предметной области и построение моделей базы данных. Для того чтобы база данных адекватно отражала предметную область  необходимо хорошо представлять себе все нюансы присущие данной предметной области, и уметь отобразить их в базе данных. Для этого в принципе может использоваться естественный  язык, но его применение имеет много недостатков, основными из них является громоздкость описания и неоднозначность его трактовки. Поэтому обычно для этих целей используют искусственные формализованные языковые средства. В связи с этим под инфологической моделью понимают описание предметной области, выполненное с использованием специальных языковых средств, не зависящих от используемых в дальнейшем программных средств. Графический способ представления исходных данных является наиболее наглядным и простым для восприятия и анализа, поэтому воспользуемся для построения инфологической модели  способом  «объект – свойство – отношение ».

       В предметной области в процессе ее обследования и анализа выделены классы объектов.

       Классом объектов называют совокупность объектов, обладающих одинаковым набором свойств.

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

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

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

       Кроме связи между объектом и его  свойствами, в инфологической модели фиксируются связи между объектами  различных классов. Различают связи  типа «один к одному» (1:1), «один  ко многим» (1:М) и «многие ко многим» (М:М).

       После условных вышеперечисленных обозначений  переходим к следующему этапу  – датологическому  проектированию. При переходе от инфологической модели к датологической следует иметь в виду, что инфологическая модель включает в себя всю информацию о предметной области, необходимую и достаточную для проектирования БД. Спроектировать датологилогическую структуру базы данных означает определить все информационные единицы и связи между ними, задать их имена, определить их тип. Следует также задать некоторые количественные характеристики, например длину поля. И так датологическим проектированием называется проектирование логической структуры базы данных в среде конкретной СУБД. Каждому объекту инфологической модели соответствует таблица созданная в среде СУБД Microsoft Access. В таблицах данные распределяются по столбцам и строкам. Столбцы (которые называют полями) служат для хранения различных характеристик объектов, а строки (которые называют записями) содержат сведения о конкретном объекте.

       Если требуется отслеживать в таблице дополнительные данные, необходимо добавить соответствующие поля. Если существующее имя поля недостаточно понятно, поле можно переименовать.

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

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

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

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

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

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

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

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

  1.5 Этапы проектирования БД  

       Целью разработки любой базы данных является хранение и использование информации о какой-либо предметной области. При проектировании базы данных решаются две основных проблемы:

       - Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области и было по возможности лучшим (эффективным, удобным и т.д.)?

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

       Таким образом, при разработке базы данных обычно выделяются три этапа моделирования, при помощи которых происходит переход  от предметной области к конкретной реализации базы данных средствами конкретной СУБД:

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

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

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

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

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

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

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

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

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