Руководство по разработке структуры и проектированию базы данных. Этапы проектирования базы данных

(ассоциация)

(характеристика)

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

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

объединение в единое целое фрагментарных представлений о различных свойствах одного и того же объекта;

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

образование классов и подклассов подобных объектов (например, класс "изделие" и подклассы типов изделий, производимых на предприятии).

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

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

ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ОПЕРАЦИОННОЙ

ОБСТАНОВКЕ.

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

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

Основные задачи:

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

Основные этапы проектирования баз данных

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

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

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

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

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

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

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

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

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

Нормализация

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

Модели «сущность-связь»

Модель «сущность-связь» (англ. “Entity-Relationship model” ), или ER-модель, предложенная П. Ченом в 1976 г., является наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной области. ER-модель обычно представляется в графической форме, с использованием оригинальной нотации П. Чена, называемой ER-диаграмма , либо с использованием других графических нотаций (Crow"s Foot , Information Engineering и др.).

Основные преимущества ER-моделей:

• наглядность;
• модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;
• ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).

Основные элементы ER-моделей:

• объекты (сущности);
• атрибуты объектов;
• связи между объектами.

Сущность - объект предметной области, имеющий атрибуты.

Связь между сущностями характеризуется:

• типом связи (1:1, 1:N, N:М);
• классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности - обязательный, иначе - необязательный.

Семантические модели

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

Дейт К. Дж. Введение в системы баз данных. - 8-е изд. - М.: «Вильямс», 2006:

Семантическое моделирование стало предметом интенсивных исследований с конца 1970-х годов. Основным побудительным мотивом подобных исследований (т.е. проблемой, которую пытались разрешить исследователи) был следующий факт. Дело в том, что системы баз данных обычно обладают весьма ограниченными сведениями о смысле хранящихся в них данных. Чаще всего они позволяют лишь манипулировать данными определенных простых типов и определяют некоторые простейшие ограничения целостности, наложенные на эти данные. Любая более сложная интерпретация возлагается на пользователя. Однако было бы замечательно, если бы системы могли обладать немного более широким объемом сведений и несколько интеллектуальнее отвечать на запросы пользователя, а также поддерживать более сложные (т.е. более высокоуровневые) интерфейсы пользователя.
[…]
Идеи семантического моделирования могут быть полезны как средство проектирования базы данных даже при отсутствии их непосредственной поддержки в СУБД.

Наиболее известным представителем класса семантических моделей является модель «сущность-связь» (ER-модель).

Литература

• Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. - 8-е изд. - М .: «Вильямс», 2006. - 1328 с. - ISBN 0-321-19784-4
• Когаловский М.Р. Перспективные технологии информационных систем. - М .: ДМК Пресс; Компания АйТи, 2003. - 288 с. - ISBN 5-279-02276-4
• Когаловский М.Р. Энциклопедия технологий баз данных. - М .: Финансы и статистика, 2002. - 800 с. - ISBN 5-279-02276-4
• Кузнецов С. Д. Основы баз данных. - 2-е изд. - М .: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. - 484 с. - ISBN 978-5-94774-736-2
• Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. - 3-е изд. - М .: «Вильямс», 2003. - 1436 с. - ISBN 0-201-70857-4
• Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. - М .: «Вильямс», 2003. - 1088 с. - ISBN 5-8459-0384-X

См. также

• Методы проектирования

Ссылки

• Модель "сущность-связь" – шаг к единому представлению о данных - Citforum
• Расширение реляционной модели для лучшего отражения семантики - Citforum
• Пособие по проектированию баз данных сайтов "для начинающих"
• Метод проектирования логической структуры реляционной БД без нормализации таблиц

Примечания

Wikimedia Foundation . 2010 .

Смотреть что такое "Проектирование баз данных" в других словарях:

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

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

ПРОЕКТИРОВАНИЕ - одна из форм опережающего отражения действительности, процесс создания прообраза (прототипа) предполагаемого объекта, явления или процесса посредством специфич. методов. П. является конкретной формой проявления прогностич. функции управления,… … Российская социологическая энциклопедия

Запрос «БД» перенаправляется сюда; см. также другие значения. База данных представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов),… … Википедия

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

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

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

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

Кафедра ИСвЭ

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

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

Выполнила: ст-ка 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 глазами хакера»;

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

Содержание проектирования баз данных и этапность

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

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

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

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

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

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

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

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

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

Ключевые из них ниже будут рассмотрены подробнее.

Инфологическое проектирование

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

• описание типов объектов,
• ограничения целостности, связанные с описанным типом,
• процессы, приводящие к эволюции предметной области – переходу её в другое состояние.

Инфологическую модель можно создавать с помощью нескольких методов и подходов:

1. Функциональный подход отталкивается от поставленных задач. Функциональным он называется, потому что применяется, если известны функции и задачи лиц, которые с помощью проектируемой базы данных будут обслуживать свои информационные потребности.
2. Предметный подход во главу угла ставит сведения об информации, которая будет содержаться в базе данных, при том, что структура запросов может не быть определена. В этом случае в исследованиях предметной области ориентируются на её максимально адекватное отображение в базе данных в контексте полного спектра предполагаемых информационных запросов.
3. Комплексный подход по методу «сущность-связь» объединяет достоинства двух предыдущих. Метод сводится к разделению всей предметной области на локальные части, которые моделируются по отдельности, а затем вновь объединяются в цельную область.

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

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

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

Следует разделять понятия «экземпляр сущности» (объект, характеризующийся конкретными значениями свойств) и понятие «тип сущности» – объект, для которого характерно общее имя и список свойств.

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

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

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

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

Выбор системы управления и программных средств БД

От выбора системы управления БД зависит практическая реализация информационной системы. Наиболее значимыми критериями в процессе выбора становятся параметры:

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

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

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

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

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

Здесь тоже находит отражение природа проектирования, которая допускает возможность (или необходимость) вернуться к концептуальной модели для её изменения в случае, если отражённые там взаимосвязи между объектами (или атрибуты объектов) не удастся реализовать средствами выбранной СУБД.

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

Схемы базы данных формируются с помощью одного из двух разнонаправленных подходов:

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

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

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

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

Построение физической модели сопряжено с решением во многом противоречивых задач:

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

Вторая задача вступает в конфликт с первой, поскольку, например:

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

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

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