Банки и базы данных как форма организации информации

Введение

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

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

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

В соответствии с поставленными целью решались следующие основные задачи:

-дать понятие компонентов банка данных;

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

-изучить классификацию банков данных;

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

-описать процесс проектирования базы данных «недвижимость» для ООО «Диалог»

Объект исследования – СУБД Microsoft Access

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

1.ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ ФУНКЦИОНИРОВАНИЯ БАЗЫ И БАНКА ДАННЫХ

1.1 Компоненты банка данных

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

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

В этом определении обозначены характерные основные черты БнД:

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

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

Основные требования, предъявляемые к БнД:

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

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

дружелюбность интерфейсов, малое время на обучение;

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

надежность хранения и защита данных.

Ядром БнД является база данных (БД).

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

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

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

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

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

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

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

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

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

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

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

Языковые средства обеспечивают взаимодействие пользователей с БД. Язык обычно включает в себя средства спецификации данных, отчетов; экранных форм, запросов и процедурные средства для описания последовательности решения задач. Язык СУБД может быть универсальным языком программирования с включением специфического подъязыка для работы с БД, например, языки универсальных систем программирования DELPHI, Visual Basic 5, Visual C++ включают язык SQL. Другие СУБД имеют специализированные языки, например, dBASE, FoxPro, Clipper, Paradox, Access. Некоторые СУБД используют только язык SQL (SQL- серверы)[2] .

Технические средства включают в себя универсальную ЭВМ, периферийные средства ввода- вывода информации, средства работы в сети.

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

Персонал - это специалисты, которые обеспечивают создание, работу и развитие БнД.

1.2 Основные задачи, решаемые персоналом банка данных

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

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

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

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

2) Администраторы банка данных. Это группа пользователей, которая на начальной стадии разработки банка данных отвечает за его оптимальную организацию с точки зрения одновременной работы множества конечных пользователей, на стадии эксплуатации отвечает за корректность работы данного банка информации и многопользовательском режиме. На стадии развития и реорганизации эта группа пользователей отвечает за возможность корректной реорганизации банка без изменения или прекращения его текущей эксплуатации[3] .

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

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

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

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД, изображенная на рис. 1

Рис. 1 Трехуровневая модель системы управления базой данных, предложенная ANSI

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

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

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

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

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

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

По назначению БнД бывают:

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

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

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

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

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

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

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

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

В открытых системах языковым средством общения с БД один из языков программирования, например C, Pascal. В таких системах для общения с БД нужен посредник, то есть программист, который владеет избранным языком программирования.

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

Одними из основополагающих в концепции баз данных являются обобщенные категории «данные» и «модель данных».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Изучение процессов преобразования входных сообщений в выходные. Прежде всего, изучаются все выходные сообщения, которые выдаются на печать или на экран и сохраняются в виде выходных массивов на МД. Это необходимо для того, чтобы определить, которые из атрибутов входных сообщений нужно сохранять в БД для получения выходных сообщений. Кроме того, на этом этапе определяются те показатели, которые получают во время решения задачи в результате выполнения определенных вычислений. По каждому расчетному показателю следует определить алгоритм его формирования и убедиться в том, что этот показатель можно получить на основе атрибутов оперативной и нормативно-справочной информации, которые были определены на втором и третьем шагах. Если определенных данных не хватает для полного выполнения расчетов, необходимо возвратиться назад, провести дополнительное исследование и определить, где и каким способом можно получить атрибуты, которых не хватает[9] .

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

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

Рис.3. Обобщенная схема процесса проектирование на внешнем уровне

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

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

2.СОЗДАНИЯ БАЗЫ ДАННЫХ В MICROSOFT ACCESS

2.1 Постановка задачи

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

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

Наименование задачи: автоматизация управления работой дилера по продаже недвижимости.

Цель работы дилера: продажа недвижимости по каталогу.

Функции дилера:

Заключение договоров на продажу недвижимости.

Ведение каталога недвижимости, предлагаемой на продажу.

Прием заказов у клиентов (покупателей) на покупку объектов недвижимости.

Работа с клиентами (маркетинг): подготовка сведений о приобретаемой недвижимости, анализ продаж, ведение справочника клиентов.

Отправка заказов фирмам – владельцам недвижимости.

Ведение расчетов за проданную недвижимость (выписка счетов).

Требования к программе:

Программа должна работать под управлением операционных систем Windows 95 или Windows NT.

Перечень вводимой информации:

О фирме – владельце:

наименование организации;

адрес;

индекс;

телефон;

О заказе:

клиент;

сотрудник;

владелец;

наименование объектов;

дата размещения;

дата оплаты;

сумма заказа.

О клиенте:

наименование организации;

адрес;

индекс;

телефон.

Об объекте недвижимости:

наименование объекта;

категория объекта;

физический адрес объекта;

страна;

владелец;

описание;

стоимость.

О сотрудниках:

фамилия;

имя;

отчество;

домашний адрес;

рабочий телефон.

Требования к оснащению офиса фирмы компьютерной техникой:

ПЭВМ не ниже Pentium 100/32/420 с операционной системой Windows 98 или Windows NT Workstation и пакетом программ MS Office.

лазерный или струйный принтер.

Проектирование информационной модели

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

Рис.4. Диаграмма взаимосвязей между бизнес-компонентами и бизнес-процессами (ER-диаграмма)

В практике проектирования информационных систем такие схемы получили название ER-диаграмм (Entity-relationship diagram (ERD) – диаграмма «Сущность-связь»). ER-диаграммы хорошо вписываются в методологию структурного анализа и проектирования информационных систем. Такие методологий обеспечивают строгое и наглядное описание проектируемой системы, которое начинается с ее общего обзора и затем уточняется, давая возможность получить различную степень детализации объекта с различным числом уровней.

Разработка бизнес-правил

Перечень бизнес-правил:

сведения о клиентах хранятся 10 лет.

оплата ожидается 3 недели, если ее не происходит, заказ уничтожается.

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

Фирма «Диалог» удерживает 5% с суммы сделки.

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

Определение объектов

Объектом называется элемент информационной системы, информацию о котором мы сохраняем. В реляционной теории баз данных объект называется сущностью[10] .

Атрибут — это информационное отображение свойств объекта. Каждый объект характеризуется рядом основных атрибутов.

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

В нашем случае объектами будут являться:

объекты недвижимости;

клиенты;

сотрудники;

заказы.

Список объектов и их атрибутов приведен в таблице 1.

Таблица 1

Перечень объектов и их атрибутов

Определение взаимосвязей между объектами

Исходя из задачи, выделим следующие сущности:

Владелец;

Недвижимость;

Клиент;

Продавец;

Заказ;

Продажа;

Счет.

Определим для включенных в модель сущностей взаимосвязи. Полученная после этого модель представлена на рисунке 5.

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

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

Следующий представляющий для нас интерес объект – объект недвижимости. Этот объект имеет атрибуты «уникальный ключ объекта», «наименование объекта» и т. д.

Третий рассматриваемый объект — заказ. Его атрибутами являются «номер заказа», «ключ клиента» и «ключ объекта недвижимости».

И четвертый рассматриваемый объект — сотрудник. Его атрибутами являются «уникальный ключ сотрудника», «имя сотрудника», «фамилия» и «отчество».

Схема взаимосвязей между атрибутами в модели приведена приложении 1.

Задание атрибутов, первичных и альтернативных ключей объектов

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

Сущность «Клиенты»:

код клиента (ключевое поле);

организация;

адрес;

индекс;

телефон;

город;

регион;

страна;

описание счета;

факс.

Сущность «Объекты недвижимости»:

код объекта недвижимости (ключевое поле);

наименование;

категория;

физический адрес;

страна;

код владельца;

описание;

стоимость.

Сущность «Заказы»:

код заказа (ключевое поле);

код клиента;

наименование;

код сотрудника;

сумма заказа;

дата размещения;

дата оплаты.

Сущность «Владельцы»:

код владельца (ключевое поле);

организация;

адрес;

индекс;

телефон;

город;

регион;

страна;

описание счета;

факс.

Сущность «Сотрудники»:

код сотрудника (ключевое поле);

фамилия;

имя;

отчество;

домашний адрес;

рабочий телефон.

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

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

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

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

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

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

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

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

Транзитивная зависимость выявляет дублирование данных в одном отношении. Если А, В и С – три атрибута одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно зависит от А. Преобразование в третью нормальную форму происходит за счет разделения исходного отношения на два.

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

Рис. 6. Схема взаимосвязей сущностей после нормализации модели

2.3 Физическое описание модели

Модель реализована в СУБД Microsoft Access 2002. В соответствии с изложенным выше, физическая модель состоит из семи таблиц, описание полей которых приведены в таблице 2.

Таблица 2

Перечень объектов и их атрибутов

2.4 Обоснование выбора СУБД

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

СУБД Access 2002 для работы с данными использует процессор баз данных Microsoft Jet 4.0, объекты доступа к данным и средство быстрого построения интерфейса — Конструктор форм. Для получения распечаток используются Конструкторы отчетов. Автоматизация рутинных операций может быть выполнена с помощью макрокоманд. На тот случай, когда не хватает функциональности визуальных средств, пользователи Access могут обратиться к созданию процедур и функций. При этом как в макрокомандах можно использовать вызовы функций, так и из кода процедур и функций можно выполнять макрокоманды.

Несмотря на свою ориентированность на конечного пользователя, в Access присутствует язык программирования Visual Basic for Application, который позволяет создавать массивы, свои типы данных, вызывать DLL-функции, с помощью OLE Automation контролировать работу приложений, которые могут функционировать как OLE-серверы. Вы даже можете целиком создавать базы данных с помощью кодирования, когда в этом появляется необходимость.

MS Access из всех рассматриваемых средств разработки имеет, пожалуй, самый богатый набор визуальных средств. Главное качество Access, которое привлекает к нему многих пользователей, – тесная интеграция с Microsoft Office. К примеру, скопировав в буфер графический образ таблицы, открыв Microsoft Word и применив вставку из буфера, мы тут же получим в документе готовую таблицу с данными из БД.

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

Посредством драйверов ISAM можно получить доступ к файлам таблиц некоторых других форматов: DBASE, Paradox, Excel, текстовым файлам, FoxPro 2.x, а посредством технологии ODBC – и к файлам многих других форматов.

Access 2002 может выступать как в роли OLE контролера, так и ОЕЕ сервера. Это значит, что вы можете контролировать работу приложений Access из любого приложения, при условии, что оно может выступать в роли OLE контролера и наоборот.

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

Разработанная модель предназначена для реализации в СУБД Microsoft Access 2002.

В ходе работы получены практические навыки постановки задач, проектирования БД, и реализации для наиболее современной СУБД – Microsoft Access 2002.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

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

Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 2000. – 351 с.

Дженнингс Р. Microsoft Access 97. - СПб.: BHV – Санкт-Петербург. – 1999. – 1270с.

Джеффри Д.Шенк. Руководство Novell. Технология клиент /сервер и ее приложения. - М.: “ЛОРИ”, 1995. - 418с.

Джонс Дж.. Access 97. Книга ответов. - С.Птб: Изд. "ПИТЕР", 1998.

Диго С.М. Проектирование и использование баз данных: Учебник – М.: Финансы и статистика, 1995.

Дрождин В.В. и др. Технология создания и использования баз данных в экономике. Учебное пособие. - Пенза: Изд-во Пенз. гос. техн. ун-та, 1995. - 91 с.

Статьи и учебные пособия сайта // http://www.helpeducation.ru

Зубов В.С. CLIPPER & FOXPRO. Практикум пользователя. - М.: Информационно - издательский дом “ФИЛИНЪ”, 1996. - 496 с.

«Информатика» базовый курс Под ред. С.В. Симоновича. — СПб.: Питер, 2001. – 642 с.

Канатников А.Н., Ткачев С.Б. Программирование в среде Clipper. - М.: Финансы и статистика, 1993 - 240с.

Каратыгин С. и др. Компьютер для Носорога. Кн. Третья. Носорог в море данных. Базы данных. - М.: ABF, 1995.

Келли Дж. Access 97. Самоучитель – СПб: Питер. - 1999. – 336с.

Microsoft Access 97. Шаг за шагом: Практ. пособ./Пер. с англ. – М.: Издательство ЭКОМ. - 1999. – 328с.

Microsoft Access 2000: Справочник. Под ред. Ю. Колесникова. — СПб.: Питер, 1999. – 420с.

Microsoft Excel 2000: справочник. Под ред. Ю. Колесникова. — СПб.: Питер, 1999. – 480 с.

Нейбауэр А. Access 97 для занятых – СПб: Питер. - 1997. – 368с.

Нортон П., Андерсен В. Разработка приложений в Access 97. – СПб.: BHV – Санкт-Петербург. – 1999. – 656с.

Системы управления базами данных. - 1996-1998г.

СУБД MS ACCESS 2.0. Практическое пособие. - М.: ЭКОМ, 1995. - 272с.

Эффективная работа с СУБД А. Рубен, А. Горев, С. Макшарипов СПб.: Питер, 2001. – 822 с.

Приложение 1

Схема взаимосвязи между атрибутами в модели

Работа предоставлена пользователем Student.km.ru.

БЕЗОПАСНОСТЬ В ТУРИЗМЕ

Вопросы развития туриндустрии, обеспечения безопасности туризма постоянно находятся в центре внимания органов государственной власти и делового туристского сообщества Москвы, Санкт-Петербурга, Республики Карелия, Московской Ленинградской, Мурманской, Астраханской, Владимирской, Костромской, Тульской, Иркутской областях, Красноярском крае и ряде других субъектов Российской Федерации.

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

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

В целях обеспечения безопасности в туризме необходимо:

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

2) Совместно с иными федеральными органами исполнительной власти рассмотреть вопрос о подготовке межведомственной федеральной программы по вопросам обеспечения безопасности туризма (с участием МВД России, МЧС России, МИД России, ФСБ России и др.), системно отражающей цели, задачи, ресурсы и технологии обеспечения безопасности различных видов туризма, деятельности субъектов туриндустрии.

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

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

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

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

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

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

9) Установить и предоставлять туристам порядок информирования, расследования и оформления акта при несчастном случае, в т.ч. на туристском транспорте.

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

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

12) Принимать от судовладельцев судна по акту соответствия мест проживания и отдыха туристов.

13) Подготовить предложения для Ростуризма, Росспорта, МЧС РФ для принятия Правил по безопасности работы российских горнолыжных центров на основе требований Международной лыжной федерации (штаб-квартира в Швейцарии), организации служб обеспечения безопасности туристов

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

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

Список литературы

При написании работы были использованы материалы сайта http://www.helpeducation.ru

Работа предоставлена пользователем Student.km.ru.

[1] Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 2000. – 351 с.

[2] «Информатика» базовый курс Под ред. С.В. Симоновича. — СПб.: Питер, 2001. – 642 с.

[3] Статьи и учебные пособия сайта // http://www.helpeducation.ru

[4] Дрождин В.В. и др. Технология создания и использования баз данных в экономике. Учебное пособие. - Пенза: Изд-во Пенз. гос. техн. ун-та, 1995. - 91 с.

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

[6] Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 2000. – 351 с.

[7] Каратыгин С. и др. Компьютер для Носорога. Кн. Третья. Носорог в море данных. Базы данных. - М.: ABF, 1995.

[8] Диго С.М. Проектирование и использование баз данных: Учебник – М.: Финансы и статистика, 1995.

[9] Microsoft Access 2000: Справочник. Под ред. Ю. Колесникова. — СПб.: Питер, 1999. – 420с.

[10] Microsoft Access 2000: Справочник. Под ред. Ю. Колесникова. — СПб.: Питер, 1999. – 420с.

[11] Эффективная работа с СУБД А. Рубен, А. Горев, С. Макшарипов СПб.: Питер, 2001. – 822 с.

Дата добавления: 05.10.2012