КУРС ЛЕКЦИЙ ПО ИНФОРМАТИКЕ Тема: Базы данных, Банки Данных, Системы Управления Базами Данных — СУБД

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

 

 

ГОУ ВПО «ВОЛОГОДСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

 

Факультет промышленного менеджмента

 

 

Кафедра технологии и оборудования автоматизированных производств

 

 

КУРС ЛЕКЦИЙ ПО ИНФОРМАТИКЕ

 

Составитель: доцент Ларин В.А.

 

 

Тема: Базы данных, Банки Данных, Системы Управления Базами Данных — СУБД

 

 

 

Вологда

 

Оглавление

Оглавление. 2

Введение. 3

1.1. История развития баз данных. 3

1.2. Файлы и файловые системы.. 6

1.3. Первый этап — базы данных на больших ЭВМ.. 10

1.4. Второй этап - эпоха персональных компьютеров. 12

1.5. Третий этап - распределенные базы данных. 16

1.6. Четвертый этап - Интранет. 18

2. Базы данных, Банки Данных, СУБД.. 19

2.1. Основные понятия и определения. 19

2.2. Языковые средства банка данных. 21

2.3. Пользователи банков данных. 25

2.4. Основные функции группы администратора БД.. 28

2.5. Архитектура базы данных. 31

2.6. Классификация банков данных. 33

2.7. Понятие категорий «данные» и «модель данных». 34

3. Проектирование баз данных. 39

3.1.Этапы проектирования баз данных. 39

3.2. Составные части инфологической модели. 49

3.3. Требования и подходы к инфологическому проектированию.. 51

3.4. Элементы модели «сущность-связь». 51

3.5. Создание инфологической модели базы данных. 55

4. Системы Управления Базами Данных. 59

4.1. Основные функции СУБД.. 59

4.2. Основные средства СУБД.. 60

4.3. СУБД в многопользовательских системах. 61

4.4. Основные свойства СУБД и базы данных. 62

4.5. Технология использования СУБД.. 63

4.5.1. Установка СУБД. 64

4.5.2. Процесс поэтапного внедрения. 64

4.5.3. Разработка структуры базы данных. 64

4.5.4. Создание базы данных средствами СУБД. 65

4.5.5 Обработка данных средствами СУБД. 65

4.6. Обзор СУБД.. 67

5. Microsoft Access. 70

Введение. 70

5.1. Еще раз о реляционной модели данных. 71

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

5.3. Стратегия разработки БД.. 75

5.4. Данные и информация. 75

5.5. Отбор необходимых данных. 76

5.6. Нормализация. 77

5.7. Чужие ключи. 79

5.8. Архитектура Microsoft Access. 79

5.9. Создание базы данных. 82

Список использованных источников. 83

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

Введение.

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

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

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

История развития баз данных

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

Файлы и файловые системы

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

Первый этап — базы данных на больших ЭВМ

В дальнейшее развитие теории баз данных большой вклад был сделан американским математиком Э.Ф.Коддом, который является создателем реляционной модели… Стремительное развитие вычислительной техники, изменение ее принципиальной… Первый этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа…

Второй этап - эпоха персональных компьютеров

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

Третий этап - распределенные базы данных

Особенности данного этапа: 1. Практически все современные СУБД обеспечивают поддержку полной реляционной… ü структурной целостности — допустимыми являются только данные, представленные в виде отношений реляционной…

Четвертый этап - Интранет

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

Базы данных, Банки Данных, СУБД

Основные понятия и определения

Современные авторы часто употребляют термины – «банк данных» и «база данных» как синонимы, однако в общеотраслевых руководящих материалах по созданию банков данных Государственного комитета по науке и технике (ГКНТ), изданных в 1982 г., эти понятия различаются. Там приводятся следующие определения банка данных, базы данных и СУБД:

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

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

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

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

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

ü ядро СУБД, которое обеспечивает организацию ввода, обработки и хранения данных,

ü компоненты, которые обеспечивают отладку системы, средства тестирования,

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

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

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

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

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

Защита информации в БД и защита БД.

Языковые средства СУБД

Рис.1. Классификация языковых средств БнД Схема имеет общий характер и ориентирована на различные СУБД. Однако не каждая СУБД, которая сейчас используется на…

Пользователи банков данных

ü Проектирование. ü Реализация. ü Эксплуатация.

Основные функции группы администратора БД

2. Проектирование структуры БД: определение состава и структуры файлов БД и связей между ними, выбор методов упорядочения данных и методов доступа к… 3. Задание ограничений целостности при описании структуры БД и процедур… ü задание декларативных ограничений целостности, присущих предметной области;

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

Рис. 3. Трехуровневая модель системы управления базой данных 1. Уровень внешних моделей — самый верхний уровень, где каждая модель имеет свое «видение» данных. Этот уровень…

Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными.

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

Классификация банков данных

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

1. информационно-поисковые;

2. специализированные по отдельным областям науки и техники;

3. банки данных АСУ для организационно-экономической информации;

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

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

По архитектуре поддерживаемой вычислительной среды БнД бывают:

ü централизованными (интегрированными) и

ü распределенными.

По виду информации, которая сохраняется, банки данных делятся на:

ü банки данных,

ü банки документов,

ü банки знаний.

По языку общения пользователя с БД различают системы с базовым языком (открытые системы) и с собственным языком (закрытые системы).

2.7. Понятие категорий «данные» и «модель данных».

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

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

На рис.4 представлена классификация моделей данных.

Рис. 4. Классификация моделей данных

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

ü организация файлов прямого и последовательного доступа,

ü индексных файлов,

ü инвертированных файлов,

ü файлов, использующих различные методы хеширования,

ü взаимосвязанных файлов.

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

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

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

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

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

Модели, основанные на языках разметки документов, связаны, прежде всего, со стандартным общим языком разметки — SGML (Standard Generalized Markup Language), который был утвержден ISO в качестве стандарта еще в 80-х годах. Этот язык предназначен для создания других языков разметки, он определяет допустимый набор тегов (ссылок), их атрибуты и внутреннюю структуру документа. Контроль за правильностью использования тегов осуществляется при помощи специального набора правил, называемых DTD-описаниями, которые используются программой клиента при разборе документа. Для каждого класса документов определяется свой набор правил, описывающих грамматику соответствующего языка разметки. С помощью SGML можно описывать структурированные данные, организовывать информацию, содержащуюся в документах, представлять эту информацию в некотором стандартизованном формате. Но ввиду некоторой своей сложности SGML использовался в основном для описания синтаксиса других языков (наиболее известным из которых является HTML), и немногие приложения работали с SGML-документами напрямую.

Гораздо более простой и удобный, чем SGML, язык HTML позволяет определять оформление элементов документа и имеет некий ограниченный набор инструкций — тегов, при помощи которых осуществляется процесс разметки. Инструкции HTML в первую очередь предназначены для управления процессом вывода содержимого документа на экране программы-клиента и определяют этим самым способ представления документа, но не его структуру. В качестве элемента гипертекстовой базы данных, описываемой HTML. используется текстовый файл, который может легко передаваться по сети с использованием протокола HTTP. Эта особенность, а также то, что HTML является открытым стандартом и огромное количество пользователей имеет возможность применять возможности этого языка для оформления своих документов, безусловно, повлияли на рост популярности HTML и сделали его сегодня главным механизмом представления информации в Internet.

Однако HTML сегодня уже не удовлетворяет в полной мере требованиям, предъявляемым современными разработчиками к языкам подобного рода. И ему на смену был предложен новый язык гипертекстовой разметки, мощный, гибкий и, одновременно с этим, удобный язык XML. В чем же заключаются его достоинства?

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

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

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

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

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

Проектирование баз данных — это пошаговый, многоэтапный процесс принятия обоснованных решений в процессе анализа информационной модели предметной… Этапы проектирования баз данных связаны с многоуровневой организацией данных.… Такое представление уровней данных не единственное. Существуют и другие варианты многоуровневого представления данных.…

Внешний уровень — подготовительный этап инфологического проектирования

Существуют два подхода к проектированию баз данных на внешнем уровне: ü «от предметной области» ü «от запроса».

Составные части инфологической модели

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

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

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

Создание инфологической модели базы данных

Разработка информационно-логической модели реляционной БД начинается с рассмотрения необходимых для её создания информационных объектов.

Если, например, представить связь между объектами "Студенты" и "Дисциплины", то вполне очевидно, что студент изучает несколько дисциплин (связь «один» обозначается одинарной стрелкой, а многозначная связь отражается двойной стрелкой). Каждая дисциплина изучается множеством студентов – это тоже многозначная связь. Следовательно, связь между объектами "Студенты" и "Дисциплины" является отношением «Многие-ко-многим» (М : М или M:N).

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

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

Системы Управления Базами Данных

Основные функции СУБД

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

Основные средства СУБД

1. средства задания (описания) структуры БД; 2. средства конструирования экранных форм, предназначенных для ввода данных,… 3. средства создания запросов для выборки данных при заданных условиях, а также выполнения операций по их…

СУБД в многопользовательских системах

Рис. 1. СУБД в многопользовательской системе В сети СУБД следит за разграничением доступа разных пользователей к общей БД и обеспечивает защиту данных при…

Основные свойства СУБД и базы данных

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

Технология использования СУБД

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

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

ü потребности разрабатываемых приложений пользователя;

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

ü требования к производительности при обработке данных;

ü наличие в СУБД необходимых функциональных средств;

ü наличие русифицированной версии СУБД;

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

Установка СУБД.

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

Процесс поэтапного внедрения.

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

Разработка структуры базы данных.

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

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

Создание базы данных средствами СУБД.

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

Обработка данных средствами СУБД.

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

Обзор СУБД

СУБД, функционирующие в среде WINDOWS, выгодно отличаются удобством пользовательского интерфейса и встроенными средствами повышения… Производительность СУБД оценивается: ü временем выполнения запросов;

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

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

Обеспечение безопасности.

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

ü шифрование прикладных программ;

ü шифрование данных;

ü защиту паролем;

ü ограничение доступа (к БД, к таблице, к словарю) для пользователя.

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

Работа в многопользовательских средах.

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

ü блокировку базы данных, файла, записи, поля;

ü идентификацию станции, установившей блокировку;

ü обновление информации после модификации;

ü контроль за временем и повторение обращения;

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

ü работу с сетевыми системами (LAN Manager, NetWare, Unix).

Импорт-экспорт.

Эта характеристика отражает:

ü возможность обработки СУБД информации, подготовленной другими
программными средствами;

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

Microsoft Access

Введение

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

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

К областям применения Microsoft Access можно отнести следующие:

ü в малом бизнесе (бухгалтерский учет, ввод заказов, ведение информации о клиентах, ведение информации о деловых контактах);

ü в работе по контракту (разработка внутриотраслевых приложений, разработка межотраслевых приложений);

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

ü в качестве персональной СУБД (справочник по адресам, ведение инвестиционного портфеля, поваренная книга, каталоги книг, пластинок, видеофильмов и т. п.).

Еще раз о реляционной модели данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стратегия разработки БД

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

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

Данные и информация

Отбор необходимых данных

Элемент данных является входным, если для выполнения задачи его необходимо прочитать в базе данных (без изменения). Например, имя и адрес клиента… Подобным образом данные являются выходными для задачи, если в этой задаче они… Данные в задаче изменяются, если они читаются в базе данных, а затем изменяются и записываются обратно. Например,…

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

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

Правило 1. Уникальность полей

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

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

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

Правило 2. Первичные ключи

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

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

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

Правило 3. Функциональная зависимость

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

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

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

Правило 4. Независимость полей

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

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

Чужие ключи

Если при создании новой таблицы в существующую таблицу включается поле, связывающее старую и новую таблицы, то это «связующее» поле называется чужим ключом или внешним ключом.

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

Архитектура Microsoft Access

1. Таблица.Объект, который определяется и используется для хранения данных. Каждая таблица включает информацию об объекте определенного типа,… 2. Запрос.Объект, который позволяет пользователю получить нужные данные из… 3. Форма.Объект, предназначенный в основном для ввода данных, отображения их на экране или управления работой…

Создание базы данных

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

Список использованных источников

1. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ.: Уч.пос.- М.: Издательский дом «Вильямс», 2000.- 1120 с. : ил.

2. Глушаков, С.В. Базы данных: учебный курс /С.В. Глушаков, Д.В. Ломотько.- Харьков. Фолио, 2002.-504с.

3. Корнелюк, В.К. «Access 2002» /В.К. Корнелюк. - М.: 2003. – 256 с.

4. Microsoft Office: СУБД Access 2003. Руководство пользователя. [Электронный ресурс.]

Оглавление