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

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

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

Реферат по дисциплине Базы данных

На тему: «Проектирование и разработка базы данных»



Содержание

Введение

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

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

Заключение

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



Введение

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

Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще - диалекты SQL и / или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. На сегодняшний день разработчик не связан рамками какого-либо конкретного пакета, а в зависимости от поставленной задачи может использовать самые разные приложения. Поэтому, более важным представляется общее направление развития СУБД и других средств разработки приложений в настоящее время.



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

Задачи и структура процесса проектирования

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

В результате ее решения должны быть определены содержание

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

• Корректность схемы БД, а именно:

- каждому объекту ПО соответствуют данные в памяти ЭВМ,

- каждому процессу ПО соответствуют адекватные процедуры обработки данных.

• Обеспечение целостности:

- формулировка ограничений,

- описание правил применения ограничений,

- описание правил обработки данных при нарушении ограничений целостности.

• Защита данных:

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

- от некорректных обновлений (согласованность методов модификации данных),

- от несанкционированного доступа (безопасность данных).

• Обеспечение ограничений на аппаратные и программные ресурсы вычислительной системы.

• Эффективность функционирования;

- эффективность использования ресурсов,

• обеспечение требований ко времени реакции системы на запросы

• и обновление БД.

• Простота и удобство в эксплуатации.

• Гибкость - возможность развития и последующей адаптации системы

• к изменениям в ПО и к новым потребностям пользователей.

Удовлетворение первых 4-х требований обязательно для принятия проекта.

В структуре процесса проектирования выделим следующие этапы:

Этап 1. Формулировка и анализ требований, включающий:

Шаг 1. Сбор и анализ априорной информации о ПО,

Шаг 2. Анализ и синтез инфологической модели ПО.

Этап 2. Проектирование концептуальной схемы.

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

На каждом из этапов решаются следующие основные задачи.

Этап 1.

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

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

- безопасность,

- надежность,

- уровень достигнутой технологии,

- политические и бюрократические ограничения.

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

Шаг 2. Описываются и анализируются разнообразные информационные требования пользователей и производится синтез первоначального проекта базы данных. Результатом этого этапа является «бумажное» высокоуровневое представление требований в виде, например, ER-модели (модели сущность-связь). На этом этапе осуществляется:

- определение сущностей,

- определение атрибутов сущностей,

- идентификация ключевых атрибутов сущностей,

- определение связей между сущностями.

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

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

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

На данном этапе проектируются также многочисленные приложения. Результатом проектирования программного обеспечения являются:

• интерфейсы приложений,

• функциональные характеристики приложений,

• наборы возможных запросов к БД,

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

• общий объем хранимых данных.

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

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

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

Шаг 1. Сбор и анализ априорной информации о ПО.

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

• что представляют собой требования пользователей;

• в какой форме они могут быть выражены;

• как требования пользователей могут быть преобразованы

• в эффективную структуру базы данных;

• какие данные используются разными приложениями; смогут

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

• сможет ли новая система объединить существующие приложения

• или их необходимо будет кардинально переделывать для совместной работы

• с новой системой;

• кто будет вводить данные в базу и в какой форме; как часто будут изменяться данные;

• достаточно ли будет для ПО одной базы или потребуется несколько

• баз данных с различными структурами;

• какая информация является наиболее чувствительной к скорости

• её извлечения и изменения;

• как часто и каким образом структура базы данных должна перестраиваться в соответствии с новыми и / или изменяющимися требованиями.

Согласно [3], на этом шаге осуществляется:

1. Определение сферы применения.

2. Сбор информации об использовании данных.

3. Преобразование информационных требований. Рассмотрим каждый из этих пунктов подробнее.

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

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

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

Пункт 2. Сбор информации об использовании данных.

Для полноты обсуждения данного пункта заметим, что информацию об использовании данных можно разделить на два вида [3]:

1. информация, связанная с производственными функциями,

2. информация, связанная с функциями управления.

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

Для каждой производственной функции у руководителей подразделений выявляется:

- наименование работы,

- выполняемая функция,

- цель выполняемой работы.

Функции управления. На этом шаг определяются:

- функции контроля и планирования и требуемые для выполнения этих функций данные,

- предположения о возможных изменениях в деятельности организации

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

• основные компоненты деятельности и их взаимодействие друг с другом,

• то есть вопросы взаимодействия различных фрагментов ПО,

• внутренняя среда, включающая:

- структуру организации,

- правила и политику, определяющие повседневную деятельность,

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

• информация, требуемая для планирования деятельности,

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

• предполагаемые изменения, которые могут влиять на род или сферу деятельности, либо на способы ведения деятельности.

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

Наименование работы	Функция	Цель
Комплектация заказов 1	Комплектация товаров со склад соответствии с заказом	Выполнение заказов клиент
Планирование запасов товаров1)	Покупка товаров	Подержка запаса товаров
Управление запасами товаров 2)	Определение оптимального количества товар и времени для их закупки	Минимизация капиталовложения при создании запаса товаров
Прием заказов 1)	Выписка заказа	Прием заказа клиента

¹⁾ - основная (производственная) функция, ²⁾ - функция управления

Идентификация производственных задач и задач управления.

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

Здесь функцию (в [3] задачу) определим как самый низкий уровень деятельности, который многократно использует уникальный набор данных.

Выделяются следующие характеристики функции:

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

• все шаги направлены на достижение одной и той же цели,

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

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

Пункт 3. Преобразование информационных требований

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

1. Составление списка всех используемых и создаваемых элементов данных.

2. Определение всех производственных функций, их характеристик

3. и используемых данных.

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

5. Составление списка всех явных и неявных правил и линий поведения

6. в управлении деятельностью организации.

7. Составление списка возможных будущих изменений и путей

8. их влияния на деятельность организации.

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

Идентификатор	Наименование	Определение
1	Номер заказа	Однозначно определяет каждый заказ
2	Заказанное количество	Определяет количество одного вида товара, заказанного одним клиентом

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

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

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

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

Итак, первый шаг предполагает:

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

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

• содержательный анализ собранной информации.

Целью содержательного анализа собранной информации является:

• устранение дублирования данных,

• выявление и устранение противоречивости данных

• и неоднозначности их определений и описаний,

• выявление и формулирование правил поведения и принятия решений

• в соответствии с описаниями ситуаций,

• выявление возможных изменений в будущем и их влияния на правила поведения и т.п.

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

• описание целей создания БД,

• описание входной и выходной информации,

• модель состава системы.

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

Шаг 2. Анализ данных и синтез инфологической модели

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

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

• объективно существующей ПО,

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

• в приложениях.

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

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

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

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

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

Общая схема инфологического проектирования

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

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

Таким образом, в результате сбора и анализа информации о ПО осуществляется:

• идентификация функциональной деятельности предметной области,

• идентификация объектов, которые осуществляют эту функциональную деятельность,

• идентификация всех сущностей и взаимосвязей между ними.

• идентификация характеристик этих сущностей.

• идентификация взаимосвязей между сущностями и их типов.

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

Очевидно, что на этом шаге проектирования реализуется свойство эмерджентности создаваемой модели.

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

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

Функциональный подход к проектированию БД

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

Предметный подход к проектированию БД

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

Проектирование с использованием метода «сущность-связь».

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

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

Заметим, что выбор сущностей (т.е. объектов, о которых в системе будет накапливаться информация) в отдельных случаях может оказаться затруднительным, поскольку порция информации может быть представлена как сущность, атрибут или связь. Например, информацию об ЭКЗАМЕНЕ можно оформить как:

• отдельную сущность,

• как атрибут сущности СЕССИЯ,

• как связь между сущностями СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА.

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

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

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

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

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

• объединение в единое целое фрагментарных представлений

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

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

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

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

При объединении представлений используют 3 основные концепции:

• идентичность. Два или более элементов модели идентичны, если они имеют одинаковое семантическое значение.

• агрегация. Позволяет рассматривать связь между элементами как новый элемент. Например, связь между сущностями СТУДЕНТ, ДИСЦИПЛИНА, ПРЕПОДАВАТЕЛЬ, ОЦЕНКА может быть представлена агрегированным элементом: сущностью ЭКЗАМЕН с атрибутами ФАМИЛИЯ-СТУДЕНТА, НАЗВАНИЕ - ДИСЦИПЛИНЫ, ФАМИЛИЯ-ПРЕПОДАВАТЕЛЯ, КОД-ОЦЕНКИ.

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

• в объединяемых представлениях присутствуют следующие сущности: ГРУЗОВЫЕ АВТОМОБИЛИ РОССИЙСКОГО ПРОИЭВОДСТВА ЛЕГКОВЫЕ АВТОМОБИЛИ РОССИЙСКОГО ПРОИЭВОДСТВА КОМПЛЕКТУЮЩИЕ РОССИЙСКОГО ПРОИЭВОДСТВА ИМПОРТНЫЕ КОМПЛЕКТУЮЩИЕ

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

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

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

Общая схема логического (концептуального) проектирования

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

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

Пример объединения сущностей

Общая структура процесса логического проектирования (включая этап инфологического проектирования) представлена схемой на рис. 7.

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

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

• Определение целей создания информационной системы.

• Определение специфических требований к БД, вытекающих из этих целей и / или сформулированных персоналом.

Этап 2.

• Определение (идентификация) сущностей (объектов).

• Определение атрибутов сущностей.

• Идентификация ключевых атрибутов сущностей.

• Определение связей между сущностями.

• Формирование инфологической модели.

Формирование и анализ требований (инфологическое проектирование)

Выбор СУБД

Проектирование реализации

Структура процесса концептуального проектирования

Этап 3. Проектирование реализации

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

• Установка (формулировка) ограничений целостности.

• Обеспечение средств защиты.

• Разработка (проектирование) приложений. Несколько комментариев

• к схеме.

К обследованию ПО:

1. Ясно, что инфологическое описание ориентировано на некоторую идеальную среду реализации, то есть отражает, что заказчик хочет отразить

2. в информационной системе, но не как эти желания будут отражены.

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

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

• номер_зачетной_книжки типа записи СТУДЕНТ (пример простого первичного ключа, состоящего из одного атрибута),

• номер_рейса + дата_вылета типа записи СВЕДЕНИЯ_О_РЕЙСАХ (пример составного первичного ключа, образованного несколькими атрибутами); знак «+» здесь означает операцию конкатенации.

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

К выбору СУБД:

1. Каждая конкретная среда реализации имеет внешние ограничения, из которых можно выделить:

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

• программные, определяемые операционной системой и языками программирования,

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

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

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

• требуемые объемы основной и дисковой памяти,

• трудоемкость разработки программных средств окружения СУБД,

• трудоемкость реализации приложений,

• затраты на обучение персонала,

• стоимость эксплуатации системы,

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

К проектированию реализаций:

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

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

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

3. их поддержку приходится возлагать на пользовательское приложение

4. (в локальных СУБД). Эти правила включают:

• определение типа данных,

• создание полей, опирающихся на домены,

• установка значений по умолчанию,

• определение ограничений целостности,

• определение проверочных условий.

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

• кто будет иметь права (и какие) на использование базы данных,

• кто будет иметь права на модификацию, вставку и удаление данных,

• нужно ли делать различие в правах доступа,

• каким образом обеспечить общий режим защиты информации, и т.п.

6. Разработка (проектирование) приложений.

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

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

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

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

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

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

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

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

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

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

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

?Каково назначение базы данных и кто будет ею пользоваться?

?Какие таблицы (данные) будет содержать база данных?

?Какие запросы и отчеты могут потребоваться пользователям этой базы данных?

?Какие формы может потребоваться создать?

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

1. Создание базы данных. Таблица в Microsoft Access.

В Microsoft Access поддерживаются три метода создания Базы данных:

1. Создание базы данных с помощью мастера

2. Создание базы данных с помощью шаблона

3. Создание пустой базы данных без помощи мастера

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

Для создания новой базы данных нужно запустить Microsoft Access 2003 из меню пуск или с помощью ярлыка. Далее в меню «файл» выберем пункт «создать», после чего появится окно следующего содержания (рис.):

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

В открывшемся поле имени файла вводим имя файла «Суд». Отмечу, что при необходимости можно выбрать папку для размещения файла базы данных. Далее нажимаем кнопку «Создать» и создаем таблицу (Рис.).



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



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

При выборе режима конструктора таблиц выводится окно «Таблица 1»: таблица в котором определяется структура таблицы базы данных список названий панелей инструментов, где отмечаются активные панели инструментов, вызывается щелчком правой кнопки мыши на любой панели инструментов или строке меню команд Access. Название кнопки на панели инструментов появляется (всплывает) при установке курсора мыши на кнопку.

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



Итак, нам необходимо создать три таблицы: «Помощники судей», «Судьи по гражданским делам», «Судьи по уголовным делам». Начнём с создания таблицы «Помощники судей». После завершения работы с определением полей таблицы которая у меня будет состоять из столбцов: «Фамилия, Имя, Отчество, Стаж, Категория дел, Судья»; закрываем её под названием «Помощники судей» с сохранением и начинаем заполнять таблицу, которую мы обнаружим сразу же после закрытия таблицы (Рис.).



Следует отметить, что тип данных столбцов «Фамилия», «Имя», «Отчество», «Категория дел», «Судья» программа автоматически определила тип данных как «Текстовый», а «Стаж» - как числовой.

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

Далее аналогии создаются таблицы: «Судьи по уголовным делам», «Судьи по гражданским делам» (Рис.).

2. Создание связей между таблицами.

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

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

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

Аналогичным образом создаем связь с таблицей «Судьи по уголовным делам» (Рис.).

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

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

3. Создание запросов в Microsoft Access.

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

В Microsoft Access после создания таблиц и организации связей между ними создаются запросы.

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

Для осуществления запроса необходимо выполнить следующие последовательные действия: В окне базы данных переходим к вкладке «ЗАПРОСЫ» и щелкаем кнопку «СОЗДАТЬ»; В диалоговом окне «НОВЫЙ ЗАПРОС» выбираем команду «Конструктор» и щелкаем кнопку OK;

В диалоговом окне «ДОБАВЛЕНИЕ ТАБЛИЦЫ» выбираем нужную вкладку; Для добавления объектов в запрос дважды щелкаем кнопкой мыши на имени каждого добавляемого объекта, а затем щелкните кнопку «ЗАКРЫТЬ».

Если запрос содержит несколько таблиц или запросов, нужно убедиться, что между собой их соединяет линия. Для Microsoft Access это означает, что данные связаны. Если же линий нет, создадим их (устанавливаем курсор мыши на связываемое поле первой таблицы, нажимаем левую кнопку мыши и, не отпуская ее, перемещаем курсор на связываемое поле другой таблицы). Добавляем поля в запрос перемещая их имена с помощью мыши из списка полей в бланк запроса. Внесём в запрос необходимые усовершенствования, а именно: определим условия отбора, порядок сортировки, создаём вычисляемые поля. Для сохранения запроса выберем пункт меню «ФАЙЛ» команду «Сохранить».

Рассмотрим форму создания запроса на примере таблицы «Судьи по гражданским делам» и «Судьи по уголовным делам». В окне запроса вводим следующее название полей: «Фамилия». В условии отбора для поля «Фамилия» вводим «=-ова, - ева» (Рис.).



4. Создание форм в Microsoft Access.

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

В Microsoft Access версии 2003 форма расположена в меню «Вставка». Созданная при помощи такой заготовки форма для таблицы «Помощники судей» выглядит так (Рис.):

база данные информационный



5. Создание отчетов в Microsoft Access.

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

В Microsoft Access можно создавать отчеты различными способами:

ЇКонструктор,

ЇМастер отчетов,

ЇАвтоотчет: в столбец,

ЇАвтоотчет: ленточный,

ЇМастер диаграмм,

ЇПочтовые наклейки.



Заключение

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

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

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

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

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

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

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

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

1. Об информации, информатизации и защите информации: Федеральный Закон от 25.01.95 №24-ФЗ // Собрание законодательства Российской Федерации, 2009. - 609 с.

2. ГОСТ 34.003-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения - Введен 1991 - 01 - 01: Изд-во стандартов, 2012. - 459 с.

3. Глушков С.В. Базы данных: Учебный курс / С. В Глушков, Д.В. Ломотько; худож. - оформитель А.С. Юхтман. - Харьков 6 Фолио; М.: ООО «Издательство АСТ», 2008.

4. Голицына О.Л. Базы данных / О.Л. Голицына. - СПб.: Питер, 2006.

5. Григорьев Ю.А. Банки данных: Учебн. для вузов / Ю.А. Григорьев, Г.А. Ревунков. - М.: Изд-во МГТУ им. Баумана, 2002.

6. Диго С.М. Базы данных / С.М. Диго. - М.: Финансы и статистика, 2005.

7. Информатика: Учебник / под ред. проф. Н.В. Макаровой. - М.: Финансы и статистика, 2010. - 598 с.

8. Калашян А.Н. Структурные модели бизнеса: DFD-технологии / А.Н. Калашян, Г.Н. Калянов; под ред. Г.Н. Калянова. - М.: Финансы и статистика, 2010.

9. Когаловский М.Р. Энциклопедия технологий баз данных / М.Р. Когаловский. - М.: Финансы и статистика, 2009.

10. Кузнецов С.Д. Базы данных. Модели и языки / С.Д. Кузнецов. - М.: Финансы и статистика, 2008.

11. Марков А.С. Базы данных. Введение в теорию и методологию: Учебник / А.С. Марков, К.Ю. Лисовский. - М.: Финансы и статистика, 2005.

12. Советов Б. Я Базы данных: теория и практика / Б.Я. Советов. - М.: Финансы и статистика, 2007.

13. Теория и практика построения баз данных. 8-е изд. / Д. Крёнке. - СПб.: ПИТЕР, 2008.

14. Хансен Г. Базы данных: разработка и управление / Г. Хансен, Д. Хансен; пер. с англ. - М.: ЗАО Издательство БИНОМ, 2010.

15. Макдональд К. Oracle PL/SQL для профессионалов. Практические решения - М.: Apress, 2005 - 560 с.

16. Молинаро Э. SQL Сборник рецептов. - М.: Apress, 2009 - 672 с.

17. Когаловский М.Р. Энциклопедия технологий баз данных. - М.: Финансы и статистика, 2002. - 800 с.

18. Справочник по SQL. Официальная документация СУБД Линтер - Воронеж, РЕЛЭКС, 2010 -380 с.

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

...