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

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

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

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

В в едение

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Свойства полей базы данных

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

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

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

Размер поля - определяет предельную длину (в символах) данных, которые могут размещаться в данном поле.

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

Маска ввода - определяет форму, в которой вводятся данные а поле (средство автоматизации ввода данных).

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

Значение по умолчанию-то значение, которое вводится в ячейки поля автоматически (средство автоматизации ввода данных).

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

Сообщение об ошибке - текстовое сообщение, которое выдается автоматически при попытке ввода в поле ошибочных данных.

Обязательное поле - свойство, определяющее обязательность заполнения данного поля при наполнении базы.

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

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

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

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

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

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

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

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

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

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

4. Разработка системного меню

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

1 - Создание файла

2 - Добавления записи

3 - Корректировка записи

4 - Просмотр записи из файла

5 - Удаление записи

6 - Выход

1 - Создание нового файла - Создается новый файл с именем задаваемым пoльзователем программы

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

Фамилия хозяина:

Имя хозяина:

марка машины:

модель маштны:

тип кузова:

номер машины:

регион:

год выпуска:

цвет:

3 - Добавление записи - Создание новой записи и файле добавляя его в конец записи.

4 - Поиск по номеру палаты - Позволяет находить данные о отдыхающем по номеру палаты, в котором зарегистрирован отдыхающий.

5 - Выход из программы - выход из программы

Вывод

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

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

Размещено на Allbest.ru

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

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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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

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

1. Вступление.

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

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

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

Примеры.

РСУБД.

РСУБД, которую я использовал для создания таблиц примеров – MySQL. MySQL – наиболее популярная РСУБД и она бесплатна.

Утилита для администрирования БД.

После установки MySQL вы получаете только интерфейс командной строки для взаимодействия с MySQL. Лично я предпочитаю графический интерфейс для управления моими базами данных. Я часто использую SQLyog. Это бесплатная утилита с графическим интерфейсом. Изображения таблиц в данном руководстве взяты оттуда.

Визуальное моделирование.

Существует отличное бесплатное приложение MySQL Workbench. Оно позволяет спроектировать вашу базу данных графически. Изображения диаграмм в руководстве сделаны в этой программе.

Проектирование независимо от РСУБД.

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

2. История.

Так выглядели профессионалы в сфере информационных технологий в 70-е. (Слева внизу находится Билл Гейтс).

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

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

Таблицы баз данных.

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

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

История реляционной модели.

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

- Oracle – используется преимущественно для профессиональных, больших приложений.
- Microsoft SQL server – РСУБД компании Microsoft. Доступна только для операционной системы Windows.
- Mysql – очень популярная РСУБД с открытым исходным кодом. Широко используется как профессионалами, так и новичками. Что еще нужно?! Она бесплатна.
- IBM – имеет ряд РСУБД, наиболее известна DB2.
- Microsoft Access – РСУБД, которая используется в офисе и дома. На самом деле – это больше, чем просто база данных. MS Access позволяет создавать базы данных с пользовательским интерфейсом.
В следующей части я расскажу кое-что о характеристиках реляционных баз данных.

3. Характеристики реляционных баз данных.

Использование ключей.

Используя структурированный язык запросов (SQL), данные из разных таблиц, которые связаны ключом, могут быть выбраны за один раз. Для примера вы можете создать запрос, который выберет все заказы из таблицы заказов (orders), которые принадлежат пользователю с идентификатором (id) 3 (Mike) из таблицы пользователей (users). О ключах мы поговорим далее, в следующих частях.

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

Отсутствие избыточности данных.

Ограничение ввода.

Когда вы создаете таблицу базы данных вы предоставляете тип данных для каждого столбца. К примеру, varchar – это тип данных для небольших фрагментов текста с максимальным количеством знаков, равным 255, а int – это числа.

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

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

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

Поддержание целостности данных.

Назначение прав.

Структурированный язык запросов (SQL).

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

Переносимость.

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

В следующей части подробнее рассмотрим первичные ключи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лекция

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

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

1. Модели многоуровневой архитектуры систем баз данных

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

Опубликованный в 1975 году отчет ANSI/X3/SPARC зафиксировал не только широкое признание концепций многоуровневой архитектуры систем баз данных, но и необходимость явного выделения специального концептуального уровня представления базы данных, единого для всех ее приложений и независимого от них. Кроме этого уровня предусматривались еще два уровня: внутренний уровень, который должен обеспечивать поддержку представления хранимой базы данных, и внешний, поддерживающий представления базы данных “с точки зрения” приложений. На каждом архитектурном уровне предполагалось использование той или иной модели данных. Кроме того, на внешнем (прикладном, пользовательском) уровне таких моделей может быть несколько. Модели, а также схемы, специфицируемые на их основе, называются, соответственно, внешней, концептуальной и внутренней.

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

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

7.2. Типология моделей

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

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

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

Однако в большинстве систем, если говорить, например, о базах данных, типы данных являются более статичным элементом, чем способы их обработки. Поэтому получили интенсивное развитие такие методы системного анализа, как диаграммы массивов данных (Data Flow Diagram). Развитие реляционных баз данных в свою очередь стимулировало развитие методик построения моделей данных, и в частности, ER -диаграмм (Entity Relationship Diagram ). Но и функциональная декомпозиция и диаграммы данных дают только некоторый срез исследуемой предметной области, но не позволяют получить представление системы в целом.

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

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

Представление схем БД в виде схем отношений упрощает процедуру проектирования БД. Этим объясняется создание си стем, в которых проектирование БД ведется в терминах реляционной модели данных, а работа с БД поддерживается СУБД одного из описанных в данном пособии типов.

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

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

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

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

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

7.3. Этапы проектирования и объекты моделирования

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

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

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

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

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

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

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

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

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

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

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

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

Можно выделить два основных подхода к проектированию баз данных: нисходящий и восходящий (слайд 7)

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

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

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

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

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

- для многих приложений трудно моделировать предметную область на основе плоских таблиц;

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

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

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

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

7.5. Инфологические модели (системный анализ) предметной области

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

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

В общем случае существуют два подхода к определению состава и структуры предметной области.(Слайд 9 Функциональный – объектный подходы)

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

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

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

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

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

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

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

7.6. Даталогические модели

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

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

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

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

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

7.7. Физические модели

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

- выбор способа организации базы данных;

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

- описание отображения концептуальной схемы во внутреннюю.

Важно заметить, что в отличие от ранних СУБД, многие современные системы не предоставляют разработчику какого-либо выбора на этой стадии. Реально к вопросам проектирования физической модели можно отнести выбор схемы размещения данных (разделение по файлам или тип RAID -массива) и определение числа и типа индексов (например, кластеризованный или некластеризованный в случае MS SQL Server ).

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

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

7.8. Средства автоматизации проектирования

Формализованные знания о предметной области в общем случае могут быть представлены в виде текстовых описаний: наборов должностных инструкций, правил ведения дел и т.п. Однако текстовый способ представления модели предметной области не эффективен. Более информативным и полезным при разработке баз данных и информационных систем являются описания предметной области, выполненные при помощи специализированных графических нотаций, реализующих методики представления знаний о предметной области. Наиболее известными на сегодняшний день являются методика структурного анализа SADT (Structured Analysis and Design Technique ) и основанная на ней нотация IDEF 0, диаграммы массивов данных, методика объектно-ориентированного анализа UML (Unified Modeling Language ) и др. Любая из этих моделей описывает, с одной стороны, процессы, происходящие в предметной области, а с другой – данные, используемые этими процессами.

Наиболее полная система моделей, на которую опираются методики функционального, информационного и поведенческого моделирования ПрО, представлена в семействе стандартов IDEF (Integrated DEFinition )(слайд 10).

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

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

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

CASE-средства в соответствии с их функциональной ориентацией на те или иные процессы жизненного цикла ИС можно подразделить на следующие группы (слайд 11 – СА SE ).

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

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

ВВЕДЕНИЕ

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