Разработка базы данных. Проектирование БД

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

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

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

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

Кафедра ИСвЭ

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

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

Выполнила: ст-ка 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. БД должна легко расширяться при реорганизации предметной области;

4. БД должна легко изменяться при изменении программной и аппаратной среды;

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

Рассмотрим основные этапы проектирования (рис. 3.5):

Первый этап . Планирование разработки базы данных. На этом этапе выделятся наиболее эффективный способ реализации этапов жизненного цикла системы.

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

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

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

Рис. 3.5. Схема проектирования БД

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

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

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

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

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

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

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

Восьмой этап . Тестирование и оптимизация. Обязательным этапом является тестирование и оптимизация разработанного приложения.

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

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

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

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

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

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. В чем заключается нормализация отношений базы данных?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имеется целый ряд методик создания информационно-логических моделей. Одна из наиболее популярных в настоящее время методик при разработке моделей использует 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 База данных

1.3 Архитектура системы баз данных

1.4 Модель данных

1.5 Реляционная модель

2. ПОСТАНОВКА ЗАДАЧИ

3. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ РЕЛЯЦИОННЫХ БАЗЫ ДАННЫХ

3.1 Реляционная алгебра

3.1.1 Общая интерпретация реляционных операций

3.1.2 Замкнутость реляционной алгебры и операция переименования

3.1.3 Особенности теоретико-множественных операций реляционной алгебры

3.2 Реляционное исчисление

3.2.1 Кортежные переменные и правильно построенные формулы

3.2.2 Целевые списки и выражения реляционного исчисления

3.2.3 Реляционное исчисление доменов

3.3 Целостность данных

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

4. РАЗРАБОТКА БАЗЫ ДАННЫХ

4.1 Предметная область базы данных

4.2 Построение инфологической модели

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

5. РАЗРАБОТКА ПРИЛОЖЕНИЯ-КЛИЕНТА

5.1 Обоснование выбора среды программирования

5.2 Средства Delphi для работы с базами данных

5.3 Реализация приложения

5.3.1 Общее описание форм и модулей

5.3.2 Форма MainForm и модуль Main

5.3.3 Модуль данных DataModule1 и модуль DBUnit

5.3.4 Форма EditForm и модуль Edit

5.3.5 Форма DeleteForm и модуль Delete

5.3.6 Форма FindForm и модуль Find

5.3.7 Форма FilterForm и модуль Filter

5.3.8 Форма DirSourceForm и модуль DirSource

5.3.9 Форма PathForm и модуль Path

5.3.10 Форма UserForm и модуль User

5.3.11 Форма AboutBox и модуль About

5.3.12 Модуль Files

6. ЭКОНОМИЧЕСКАЯ ЧАСТЬ

6.1 Предметная область базы данных и её разработка

6.2 Разработка сетевого графика работ проведения НИР

6.3 Расчет сметы затрат на проведение НИР

7. ОХРАНА ТРУДА

7.1 Общие вопросы охраны труда

7.2 Производственная санитария

7.3 Техника безопасности

7.4 Эксплутационные меры

7.5 Пожарная безопасность

7.6 Охрана окружающей среды

8. ГРАЖДАНСКАЯ ОБОРОНА

СПИСОК ССЫЛОК

ПРИЛОЖЕНИЯ

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

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

Для управления базой данных была выбрана СУБД InterBase 6.0 фирмы Borland. Для разработки клиентской части приложения использовалась среда программирования Borland Dalphi 7.0 Eneterprise Edition, предоставляющая удобные средства для быстрого и наглядного создания подобных приложений.

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

1. АНАЛИТИЧЕСКИЙ ОБЗОР ЛИТЕРАТУРНЫХ ИСТОЧНИКОВ

1.1 Основные понятия систем баз данных

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

Преимущества системы с базой данных по сравнению традиционным методом ведения учёта:

1) компактность;

2) скорость;

3) низкие трудозатраты;

4) актуальность;

5) централизованное управление данными;

6) независимость данных.

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

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

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

К аппаратному обеспечению системы относят следующее:

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

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

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

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

Таблица «Счет» Таблица «Товар» Таблица «Товар по счету» Таблица «Товарные группы» Лабораторная работа № 2. Разработка запросов отбора данных и вычислений Цель работы приобретение навыков в описании запросов к базе данных на языке QBE (Query by Example). Выборка неоплаченных счетов Результат выполнения: Выборка поставок Результат выполнения: Поиск...

Проекта 1. Введение. Целью данного курсового проекта является структурирование данных и разработка пользовательского интерфейса. В курсовом проекте рассмотрены следующие теоретические вопросы и практические задания: ü проведен системно-комплексный анализ выбранного объекта автоматизации ü разработана структура пользовательского интерфейса автоматизированной системы...