Темы: этапы проектирования баз данных, проектирование базы данных на основе модели типа объект — отношение.

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

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

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

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

Этапы проектирования и создания базы данных определяются следующей последовательностью:

Построение информационно-логической модели данных предметной области;

Определение логической структуры реляционной базы данных;

Конструирование таблиц базы данных;

Создание схемы данных;

Ввод данных в таблицы (создание записей);

Разработка необходимых форм, запросов, макросов, модулей, отчетов;

Разработка пользовательского интерфейса.

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

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


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

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

Рассмотрим формальные правила, которые могут быть использованы для выделения информационных объектов:

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

Определить функциональные зависимости между атрибутами;

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

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

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

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

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

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

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

Проектирование базы данных на основе модели типа объект — отношение

Имеется целый ряд методик создания информационно-логических моделей. Одна из наиболее популярных в настоящее время методик при разработке моделей использует ERD (Entity-Relationship Diagrams). В русскоязычной литературе эти диаграммы называют «объект — отношение» либо «сущность — связь». Модель ERD была предложена Питером Пин Шен Ченом в 1976 г. К настоящему времени разработано несколько ее разновидностей, но все они базируются на графических диаграммах, предложенных Ченом. Диаграммы конструируются из небольшого числа компонентов. Благодаря наглядности представления они широко используются в CASE-средствах (Computer Aided Software Engineering).

Рассмотрим используемую терминологию и обозначения.

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

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

Каждая сущность должна обладать некоторыми свойствами:

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

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

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

Сущность может быть независимой либо зависимой. Признаком зависимой сущности служит наличие у нее наследуемых через связь атрибутов (рис. 1.).

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

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

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

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

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

Продавец может получить вознаграждение за один или более Контрактов;

Контракт должен быть инициирован ровно одним Продавцом.

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

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

Экземпляр атрибута — это определенная характеристика конкретного экземпляра сущности. Экземпляр атрибута определяется типом характеристики (например, «Цвет») и ее значением (например, «лиловый»), называемым значением атрибута. В ER-модели атрибуты ассоциируются с конкретными сущностями. Каждый экземпляр сущности должен обладать одним конкретным значением для каждого своего атрибута.

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

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

Характер идентификации отображается в диаграмме на линии связи (рис. 4).

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

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

В настоящее время на основе подхода Чена создана методология IDEF1X , которая разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEFlX-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).

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

Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой «/» и помещаемые над блоком.

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

Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией. На рис. 5: №2 — зависимая сущность, Связь 1 — идентифицирующая связь. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).

Штриховая линия изображает неидентифицирующую связь. На рис. 5: №4 — независимая сущность, Связь 2 — неидентифицирующая связь. Сущность-потомок в неидентифицируюшей связи будет независимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.

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

В IDEF1X могут быть выражены следующие мощности связей:

Каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;

Каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

Каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;

Каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

Мощность связи обозначается, как показано на рис. 6 (мощность по умолчанию — N).


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

В результате получается информационно-логическая модель, которая используется рядом распространенных CASE-средств, таких, как ERwin, Design/IDEF. В свою очередь, CASE-технологии имеют высокие потенциальные возможности при разработке баз данных и информационных систем, а именно, увеличение производительности труда, улучшение качества программных продуктов, поддержка унифицированного и согласованного стиля работы.

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

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

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

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

1. Определение назначения базы данных.

2. Принятие решения о том, какие исходные данные база данных должна содержать.

3. Определение исходных таблиц базы данных.

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

5. Назначение связей между таблицами и окончательный просмотр получившейся структуры.

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

7. Создание форм, отчетов и запросов для операций с введенными данными.

Определение назначения базы данных

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

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

Выбор информации, включаемой в базу

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

2. Название книги.

3. Место издания (город).

4. Издательство (название издательства).

5. Год выпуска.

6. Аннотация.

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


1. Номер комнаты (помещения для хранения книг).

2. Номер стеллажа в комнате.

3. Номер полки на стеллаже.

4. Номер (инвентарный номер книги).

5. Дата приобретения.

6. Дата размещения конкретной книги на конкретном месте.

7. Дата изъятия книги с установленного места.

К атрибутам, позволяющим охарактеризовать читателей, можно отнести:

1. Номер читательского билета (формуляра).

2. Фамилия читателя.

3. Имя читателя.

4. Отчество читателя.

5. Адрес читателя.

6. Телефон читателя.

7. Дата выдачи читателю конкретной книги.

8. Срок, на который конкретная книга выдана читателю.

9. Дата возврата книги.

Определение исходных таблиц

Анализ определенных выше объектов и атрибутов позволяет определить для проектируемой базы данных следующие таблицы для построения базы данных:

2. Книги . Таблица предназначена для хранения сведений о книгах.

3. Издательства .Таблица предназначена для хранения сведений об издательствах.

4. Хранилище . Таблица предназначена для описания места хранения книг.

5. Выдача .Таблица предназначена для хранения сведений о выданных книгах.

6. Читатели .Таблица предназначена для хранения сведений о читателях библиотеки.

Выбор необходимых полей таблиц

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

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

Книги:

· код книги – числовое поле, предназначено для однозначного определения каждой конкретной книги в базе данных;

· название книги

· аннотация – текстовое поле;

· дата издания ;

· дата поступления в библиотеку ;

· место хранения .
Издательства:

· код издательства – числовое поле, предназначено для однозначного определения каждого конкретного издательства в базе данных;

· название издательства – символьное поле, не более 256 символов;

· город, где расположено издательство – символьное поле, не более 25 символов.

Хранилище:

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

· номер комнаты – числовое поле;

· номер стеллажа – числовое поле;

· номер полки – числовое поле.

Выдача:

· код выдачи – числовое поле, предназначено для однозначного определения каждой конкретной выдачи в базе данных;

· номер выданной книги – числовое поле;

· код читателя – числовое поле;

· дата выдачи ;

· срок выдачи (количество дней);

· дата возврата .

Читатели:

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

· фамилия

· имя – символьное поле, не более 50 символов;

· отчество – символьное поле, не более 50 символов;

· адрес – символьное поле, не более 256 символов;

· телефон – символьное поле, не более 20 символов.

Выбор уникальных полей

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

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

· Книги – код книги .

· Издательства – код издательства .

· Хранилище – код места .

· Выдача – код выдачи .

· Читатели – номер билета .

Назначение связей между таблицами

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

· один-к-одному – каждая запись таблицы А не может быть связана более чем с одной записью таблицы Б;

· один-ко-многим – одна запись в таблице А может быть связана со многими записями таблицы Б (например, в каждом классе может быть много учеников);

· многие-ко-многим – каждая запись в таблице А может быть связана со многими записями в таблице Б, а каждая запись в таблице Б – со многими записями в таблице А (например, у каждого учащегося может быть несколько преподавателей, а у каждого преподавателя может быть много учеников).

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

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

В нашей базе данных установим следующие типы связей между таблицами:

1. Авторы – Книги. Здесь связь многие-ко-многим , у любого автора может быть более одной книги, и любая книга может быть написана несколькими авторами. Поэтому вводим вспомогательную таблицу «Авторы–книги» со следующими полями:

· код книги .

2. Книги – Издательства. Здесь связь многие-ко-многим , любая книга может быть издана несколькими издательствами и любое издательство издает не одну книгу. Поэтому вводим еще одну вспомогательную таблицу «Книги–издательства» со следующими полями:

· код книги ;

· код издательства .

3. Хранилище – Книги. Здесь связь один-ко-многим , на одной полке можно расставить множество книг, но любая книга может быть только на одной полке в хранилище. Поэтому поле «Место хранения» в таблице «Книги» определяем как внешний ключ, и связываем таблицы «Хранилище» и «Книги» первичным ключом «Код места» и внешним ключом «Место хранения».

4. Книги – Выдача. Здесь связь один-ко-многим , т.е. одна и та же книга может быть выдана несколько раз в разные даты разным читателям. Поэтому поле «Номер выданной книги» в таблице «Выдача» определяем как внешний ключ, и связываем таблицы «Книги» и «Выдача» первичным ключом «Код книги» и внешним ключом «Номер выданной книги».

5. Читатели – Выдача. Здесь связь один-ко-многим , т.е. одна и та же книга может быть выдана несколько раз разным читателям в разные сроки. Поэтому поле «Код читателя» в таблице «Выдача» определяем как внешний ключ, и связываем таблицы «Читатели» и «Выдача» первичным ключом «Номер читательского билета» и внешним ключом «Код читателя».

Нормализация отношений

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

Правило 1: каждое поле таблицы должно представлять уникальный тип информации.

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

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

В спроектированной нами базе данных все таблицы (за исключением вспомогательных «Авторы – книги» и «Издательства – книги») содержат первичный ключ.

Правило 3: для каждого значения первичного ключа значения в столбцах данных должны относиться к объекту таблицы и полностью его описывать.

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

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

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

Наполнение базы данных, создание форм и отчетов

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

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

Полученная схема данных разработанной БД в MS Access представлена на рис. 4.1.

Рис. 4.1. Схема данных разработанной БД в Microsoft Access

Контрольные вопросы

1. Дайте определение информационной системы.

2. Поясните понятие базы данных.

3. Что такое предметная область?

4. Дайте определение СУБД.

5. Что такое модель данных?

6. Поясните основные принципы реляционной модели данных.

7. Поясните особенности СУБД Microsoft Access.

8. Каковы основные объекты базы данных Access?

9. Поясните структуру таблицы Access.

10. Поясните понятия: запрос, форма, отчет, страница доступа к данных, макрос, модуль.

11. Каковы основные этапы проектирования базы данных?

12. Каким образом осуществляется выбор информации, включаемой в базу данных?

13. Поясните понятия: первичный ключ, внешний ключ.

14. Каково назначение связей между таблицами?

15. Поясните основные типы связей между таблицами.

16. В чем заключается нормализация отношений базы данных?

Министерство образования и науки РФ

Федеральное агентство по образованию

Дагестанский Государственный Технический Университет

Факультет Информационных Систем

Кафедра ИСвЭ

Курсовой проект

«Разработка базы данных»

Выполнила: ст-ка 3 курса

Гр. И411 Вагабова П.Х.

Проверил: ст. преподаватель

Каф. ИСЭ Мурадов М.М.

Махачкала 2006г.

1.Введение

Теоритическая часть

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

2 «Проектирование БД»

3 «Обзор современных СУБД»

4 «Обоснование выбора технических средств»

Проектная часть

1 Модули программ

2 Описание работы с программой

Заключение

Литература

Приложение

1.Введение

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

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

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

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

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

2. Теоретическая часть

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

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

Так как XXI век- век компьютерной техники, то просто не имеет смысла вести учёт вручную, перебирать кипу бумаг в надежде найти то, что нас интересует, достаточно сформировать БД в C++Builder и поиск нужных данных будет осуществляться намного быстрее.

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

В моей курсовой учёт ведётся по следующим полям:

· ФИО мастера,

· Номер машины,

· Количество выпущенной продукции,

· Наименование изделия,

· Материал,

· Артикул ткани,

· Название ткани,

· Производитель ткани,

· Расход ткани,

· Цена ткани,

· Артикул красителя,

· Название красителя,

· Производитель красителя,

· Расход красителя,

· Цена красителя.

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

2 Проектирование БД

В БД отражается определенная информация о предметной области.

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

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

Инфологическая модель:

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

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

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

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

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

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

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

Требования, предъявляемые к инфологической модели:

Адекватное отображение предметной области- язык для представления ИЛМ должен обладать достаточными выразительными возможностями для отображения явлений, имеющих место в предметной области.

Непротиворечивость - не должна, допускаться неоднозначная трактовка модели.

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

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

Должна обладать свойствами декомпозиции и композиции (укреплять базу данных или расщеплять).

Должна быть легко реализуемой на ЭВМ.

Должна быть независимой от оборудования и языков организации БД на ЭВМ.

Основные конструктивные элементы инфологической модели:

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

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

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

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

Даталогическая модель базы данных (ДЛМ):

В отличие от инфологической модели данных даталогическая модель является компьютеро-ориентированной. Эта модель строится в терминах информационных единиц, допустимых в той конкретной СУБД, в среде которой мы проектируем базу данных. Этап создания ДЛМ называется даталогическим проектированием. Описание логической структуры базы данных на языке СУБД называется схемой.

Физическая модель БД:

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

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

В настоящее время наблюдается тенденция к сокращению работ на стадии физического проектирования. Иногда эти работы вообще бывают скрыты от проектировщика.

база данное язык программирование

2.3 Обзор современных СУБД

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

В наиболее полном варианте пакеты СУБД должны иметь следующие компоненты:

Среда пользователя, дающая возможность непосредственно управления БД.

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

Компилятор для придания завершенной программе готового коммерческого вида, в виде exe-файла.

Программы- утилиты быстрого программирования рутинных операций, такие как FORM, MENU.

СУБД является пользовательской оболочкой, ориентированной на немедленное управление запросов пользователя. Однако для отечественного пользователя это представляет меньшую значимость вследствие трудности овладения англоязычным интерфейсом. Наличие в СУБД языка программирования позволяет создавать сложные системы обработки данных для конкретных задач. Группа реляционных СУБД представлена на рынке программных продуктов достаточно широко. Это, например, такие системы как Paradox, Clipper.

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

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

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

Известно много программных продуктов, позволяющих создавать и работать с БД, например, Access, Clipper, Excel и другие. Среди большого разнообразия программ наибольшей популярностью пользуется СУБД FoxPro, которая по своим характеристикам удовлетворяет самым высоким требованиям, предъявляемым такого типа системам как по уровню и объему, так и по скорости обработки информации.

На данный момент разработано и широко используется Visual FoxPro для Windows версий 3.0 и 5.0. Однако, работа с этими пакетами для непрограммистов представляет собой довольно сложную задачу. Поэтому для создания БД для пользователей, имеющих небольшой опыт в программировании, очень удачными являются версии 2.5 и 2.6 под Windows и 2.0 под DOS.

Структура Базы данных:

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

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

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

Среда разработки Borland С++ Builder.

Для создания автономного рабочего места можно выбрать программные средства языка « С++ Builder» , которое является одной из наиболее известных СУБД. На рынке программных продуктов есть много средств для автоматизации программирования. Но по мощности и удобству использования со средой Builder может соперничать лишь Borland Delphi и Microsoft Visual Basic.

« С++ Builder» является мощной системой визуального объектно-ориентированного программирования, которая позволяет работать как с простыми локальными удаленными БД, так и с многозвенными распределенными БД. Она сама и поставляемые с ней программные продукты позволяют решать следующий круг задач:

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

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

Создавать удобный интерфейс любым ранее созданным программам.

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

Создавать системы работы с локальными и удаленными БД любых типов.

Создавать БД различных типов с помощью инструментария С++ Builder (DataBaseDesktop).

Форматировать и печатать из приложения сложные отчеты, включающие в себя таблицы, графики, самого разного обозначения.

Связываться со своего приложения с такими продуктами Microsoft как Word, Excel и др.

Создавать систему помощи, как для своих приложений, так и для других.C++Builder 6 - это программа, созданная для управления данными - каталогизации, поддержки, обработки информации и многое другое. Хотя Вы можете производить многие операции базы данных через систему меню и интерфейс, овладение обширными возможностями Borland C++Builder 6 требует некоторого знания лежащего в основе языка программирования.

Приложения в среде Borland С++ Builder 6 строятся в виде специальных конструкций - проектов, которые выглядят для пользователя как совокупность нескольких файлов. Ни одна программа не может существовать вне структуры-проекта. Действия по управлению проектами осуществляет специальный программный комплекс - Менеджер проектов.

4 Обоснование выбора технических средств

Минимальные системные требования:

Операционная система Microsoft Windows 98, Windows Millennium (Me), Windows 2000 и поздние версии операционных систем Microsoft Windows.

3. объем оперативной памяти должен составлять не менее 128 Mb (256 Mb рекомендуется).

4. 115 Mb свободного места на жестком диске.

VGA или более высокое разрешение монитора.

Мышь, клавиатура.

Пространство на жестком диске, необходимое для полной установки: 675 Mb (Enterprise edition); 580 Mb (Professional); 480 Mb (Personal)

3. Проектная часть

Задание: Выпуск продукции и расход сырья. Структура файлов БД:

ФИО мастера, дата выпуска, номер машины, количество выпущенной продукции, наименование изделий, артикул ткани, название ткани, производитель ткани, расход ткани, цена ткани, артикул красителя, название красителя, производитель красителя, расход красителя, цена красителя.

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

На основании теоретических данных построим инфологическую (Рис.3.1) и даталогическую (Таб.3.1, Таб.3.2) модели данных.

Рис.3.1 инфологическая модель предметной области.

Таблица 3.1.

«Схема данных выпуск продукции и расход сырья»

наименование

назначение

размерность

ФИО мастера

дата выпуска

номер машины

кол.вып продукции

наим. изделий

материал

Таблица 3.2.

«Схема данных материал»

наименование

назначение

размерность

материал

артикул ткани

название ткани

произволитель ткани

расход ткани

цена ткани

артикул красителя

название красителя

произволитель красителя

расход красителя

цена красителя

Схема таблиц.

Откроем Пуск->Программы->Borland C++ Builder 6->BDE Administrator. Создадим БД: Object->New и назовем ее «КБД».

Откроем Пуск->Программы->Borland C++ Builder 6->Database Desktop. В ней создадим две таблицы (New->Table), которые назовем:

3.1 Модули программ

Данное приложение содержит одну главную форму Form1. Она запускает ряд процедур, которые являются модулями программ.

Список процедур:

Table1AfterScroll- обеспечивает отображение данных Таблицы1 (“t1.db”) в окне редактирования при перемещении по таблице.AfterScroll- обеспечивает отображение данных Таблицы2 (“t2.db”) в окне редактирования при перемещении по таблице.Click- обеспечивает отображение данных таблиц в окне редактирования при перемещении по таблице с помощью компоненты навигации по базе данных.Click- переводит Таблицы 1 и 2 (“t1.db” , “t2. db ”) в состояние режима вставки (dsInsert), а также очищает поля ввода данных.Click- редактирует содержимое Таблиц 1 и 2 (“t1.db” , “t2. db”).Click- сохраняет данные, внесенные в окна редактирования, для Таблиц 1 и 2 (“t1.db ” “t2.db”).Click- удаляет данные из Таблиц 1 b 2 (“t1.db ” и “t2.db”).Click- очищает поля ввода данных.Click- выводит отчет QuickRep1 на экран.Click- выводит отчет QuickRep1 на печать.Click- осуществляет переход на Form2.Click- осуществляет выход из программы.Click- осуществляет фильтрацию Таблицы1 (“t1.db”).Change- осуществляет фильтрацию Таблицы1 (“t1.db”) по полю N_mash Change- осуществляет фильтрацию Таблицы1 (“t1.db”) по полю Naim_iz Change- осуществляет поиск данных Таблицы1 (“t1.db”) по полю Fio_vas(используется метод Locate).Change- осуществляет поиск данных Таблицы1 (“t1.db”) по полю Data_v(используется метод Locate).

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

Схема взаимосвязи программных модулей:

2 Описание работы с программой

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

Операция ввода позволяет вводить в базы данных следующие данные: ФИО мастера, дата выпуска, номер машины, количество выпущенной продукции, наименование изделия, материал, артикул ткани, название ткани, производитель ткани, расход ткани, цена ткани, артикул красителя, название красителя, производитель красителя, расход красителя, цена красителя. Для того чтобы осуществить ввод новых данных необходимо нажать на кнопку Ввод -> ввести нужные данные в поля ввода -> Сохранить.

Нажав Удалить, можно удалить запись. Редактировать запись можно следующим образом: к примеру в Edit1 введём новую фамилию мастера и нажмём на кнопку «редактировать», изменения должны отобразиться в таблицах.

Просмотр - дает возможность увидеть внесенные изменения. Печать - выводит на принтер готовый документ.

Поиск осуществляется по ФИО мастера и дате выпуска. Введя в поле ввода ФИО нужного нам мастера, будут высвечиваться все данные об этом мастере. Фильтрация осуществляется по номеру машины и наименованию изделия. К примеру мы можем ввести в поле Edit34 наименование изделия, установить значок «наименование изделия» и в наших таблицах выведутся все данные относительно этого изделия.

4.Заключение

В результате проделанной работы я ознакомилась с программой C++Builder и создала БД «выпуск продукции и расход сырья».

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

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

5. Литература

1. Диго С.М. “Использование и проектирование базы данных”.

2. Курс лекций по дисциплине “Базы данных”.

Никита Культин “Самоучитель С++ Builder ” Санкт-Петербург <<БВХ-Петербург>> 2004 г.

Хеннер Е.К., Могилев А.В., Пак Н.И. «Информатика». М.: «Учебное пособие для студентов пед. вузов», 1999 г.

Б. Бабэ «Просто и ясно о Borland C++»;

Т. Сван «Программирование для Windows в Borland C++ Builder»;

Д. Холингворт, Б. Сворт, М. Кэшмэн, П. Густавсон «Borland С++ Builder»;

М. Фленов «Программирование на Borland C++ Builder глазами хакера»;


Рис. 3.5.

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

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

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

В процессе логического проектирования высокоуровневое представление данных преобразуется в структуру используемой СУБД . Основной целью этапа является устранение избыточности данных с использованием специальных правил нормализации.

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

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

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

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

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

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

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

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

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

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

Основными причинами низкой эффективности проектируемых БД могут быть:

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

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

Основные этапы разработки БД

Этап 1. Уточнение задач

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

Этап 2. Последовательность выполнения задач

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

Этап 3. Анализ данных

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

Этап 4. Определение структуры данных

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

Этап 5. Разработка макета приложения и пользовательского интерфейса

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

Этап 6. Создание приложения

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

Этап 7. Тестирование и усовершенствование

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

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

хорошую работу на сайт">

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

Размещено на http://www.allbest.ru/

В в едение

интерфейс программа пользователь системный

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

количество компьютеров в мире сровняется с числом жителей развитых стран.

большинство этих компьютеров будет включено в мировые информационные сети.

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

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

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

1. База данных и способы ее представления

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

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

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

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

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

2. Свойства полей базы данных
Поля базы данных не просто определяют структуру базы - они еще определяют групповые свойства данных, записываемых в ячейки, принадлежащие каждому из полей. Ниже перечислены основные свойства полей таблиц баз данных на примере СУБД Pascal 7.0.
Имя поля - определяет, как следует обращаться к данным этого поля при автоматических операциях с базой (по умолчанию имена полей используются в качестве заголовков столбцов таблиц).
Тип поля - определяет тип данных, которые могут содержаться в данном поле.
Размер поля - определяет предельную длину (в символах) данных, которые могут размещаться в данном поле.
Формат поля - определяет способ форматирования данных в ячейках, принадлежащих полю.
Маска ввода - определяет форму, в которой вводятся данные а поле (средство автоматизации ввода данных).
Подпись - определяет заголовок столбца таблицы для данного поля (если подпись не указана, то в качестве заголовка столбца используется свойство Имя поля).
Значение по умолчанию-то значение, которое вводится в ячейки поля автоматически (средство автоматизации ввода данных).
Условие на значение - ограничение, используемое для проверки правильности ввода данных (средство автоматизации ввода, которое используется, как правило, для данных, имеющих числовой тип, денежный тип или тип даты).
Сообщение об ошибке - текстовое сообщение, которое выдается автоматически при попытке ввода в поле ошибочных данных.
Обязательное поле - свойство, определяющее обязательность заполнения данного поля при наполнении базы.
Пустые строки - свойство, разрешающее ввод пустых строковых данных (от свойства Обязательное поле отличается тем, что относится не ко всем типам данных, а лишь к некоторым, например к текстовым).

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

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

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

3 . Це ли и задачи

При создании этой программы стояли следующие цели:

· Написать программу, которая позволила бы обрабатывать, сортировать и изменять информацию о автостоянки.

Так же при создании этой программы стояли следующие задачи:

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

· Данная программа должна иметь малую ресурсоёмкость.

4. Разработка системного меню
Системное меню или основное меню должно обеспечивать удобное взаимодействие пользователя с программой. В меню должны войти пункты сохранения, просмотра, ввода новых данных и.т.д. Пользователю нужно всего лишь нажать кнопку `enter". В меню данной программы присутствует шесть пунктов:
1 - Создание файла
2 - Добавления записи
3 - Корректировка записи
4 - Просмотр записи из файла
5 - Удаление записи
6 - Выход
1 - Создание нового файла - Создается новый файл с именем задаваемым пoльзователем программы
2 - Просмотр содержимого файла - на экран поочередно выдаются раннее созданные записи в виде:
Фамилия хозяина:
Имя хозяина:
марка машины:
модель маштны:
тип кузова:
номер машины:
регион:
год выпуска:
цвет:
3 - Добавление записи - Создание новой записи и файле добавляя его в конец записи.
4 - Поиск по номеру палаты - Позволяет находить данные о отдыхающем по номеру палаты, в котором зарегистрирован отдыхающий.
5 - Выход из программы - выход из программы
Вывод
Проделанная работа позволяет любому пользователю с легкостью создавать большие объемы информации, обрабатывать их, сортировать, делать выборки по определенным критериям.
Использование такой программы в современном мире значительно облегчает деятельность человека.
Размещено на Allbest.ru

Подобные документы

    Определение необходимых модулей программы, структуры файла базы данных. Описание разработки программы, отладка и тестирование. Разработка приложения Organizer.exe, меню и руководство пользователя. Алгоритм обработки событий главного меню (расписания).

    курсовая работа , добавлен 11.02.2014

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

    курсовая работа , добавлен 08.06.2012

    Выбор состава технических и программных средств разработки системы. Описание входных и выходных данных. Выбор модели базы данных. Разработка подсистемы наполнения базы данных, формирования отчетов. Разработка интерфейса пользователя, тестирование системы.

    курсовая работа , добавлен 04.12.2014

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

    курсовая работа , добавлен 14.02.2011

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

    курсовая работа , добавлен 18.12.2010

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

    дипломная работа , добавлен 18.05.2013

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

    курсовая работа , добавлен 26.03.2013

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

    курсовая работа , добавлен 13.11.2012

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

    лабораторная работа , добавлен 13.06.2014

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