СОДЕРЖАНИЕ

ВВЕДЕНИЕ

ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

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

1.2. Инфологическое моделирование

ГЛАВА 2. Инфологическое проектирование

2.1. Модель «сущность-связь»

2.2. Связи между сущностями

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

ВВЕДЕНИЕ

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

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

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

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

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

- целостность и непротиворечивость данных,

- достоверность данных,

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

- безопасность доступа к данным.

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

ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

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

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

Программа работает в ОС Windows 95/98/ME, Windows 2000/2003/NT/XP. Минимальные требования: компьютер, на котором способна работать какая-нибудь Windows, 4 Мбайта места на жестком диске плюс размер данных. Разрешение экрана монитора должно быть не менее чем 800x600.

Программа "Прокат " работает на одном или нескольких компьютерах операторов пункта проката и выполняет следующие основные функции:

· Регистрация клиентов, формирование и печать персональных карточек клиентов

· Ввод товаров, печать этикеток товаров. Имеются средства для разработки дизайна карточек клиентов и этикеток товаров

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

· Выдача и возврат из проката, резервирование (заказ) и продажа товаров с регистрацией всех операций в журнале учета

· Гибкая система настройки различных схем обслуживания клиентов в зависимости от их Категории: залоговая, абонементная, предоплата, VIP...

· Прием оплаты от клиентов, печать чеков, приходных и расходных ордеров, актов, счетов-фактур, договора с клиентом и т.п.

· Учет взаиморасчетов с каждым клиентом за всю историю, возможность применения различных схем взаиморасчетов

· Всевозможные отчеты по товарам: каталоги, по популярности, справки о наличии...

· Экспорт данных в Excel и формирование там документа "Учет доходов предпринимателя"

· Различные отчеты по клиентам, справка о должниках, справка о клиенте

· Отчеты по оборотам за день, за произвольный период

· Возможность блокировки, разблокировки, и замены карточки клиента. Занесение клиента в "черный список"

· Возможность работы в любой валюте (рубли, гривны, USD, EUR и т.п.)

· Возможность автоматической печати чеков на кассовом аппарате АМС-100Ф

· Разграничение доступа к функциям системы для сотрудников пункта проката

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

· Подробная справочная система, техническая поддержка пользователей

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

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

1.2. Инфологическое моделирование

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

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

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

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

Сущность имеет имя, уникальное в пределах модели. При этом имя сущности – это имя типа, а не конкретного экземпляра.

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

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

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

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

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

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

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

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

ГЛАВА 2. ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

2.1. Модель «сущность-связь»

Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь" или называемая ещё ER-моделью (от англ. Entity-Relationship, т.е. сущность-связь).

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

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

Связи делятся на три типа по множественности: один-ко-одному (1:1), один-ко-многим (1:М), многие-ко-многим (М:М).

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

Связь один-ко-многим (1:М) означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи.

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

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

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

рис.1. «Справочник клиентов»

рис.2. «Видеотека»

рис.3. «Заказы»

Рис.4. «Сотрудники»

2.2. Связи между сущностями

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

Связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В (рис.4).

рис.4. Связь ОДИН-КО-МНОГИМ

рис.5. Моделирование связей между сущностями предметной области

ЗАКЛЮЧЕНИЕ

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

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

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

Целесообразно:

· четко разграничивать такие понятия как запрос на данные и ведение данных (ввод, изменение и удаление);

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

· плохой проект базы данных не может быть исправлен с помощью любых (даже самых изощренных) приложений.

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

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

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

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

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

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

Создание АИС способствует повышению эффективности производства экономического объекта и обеспечивает качество управления.

СПИСОК ЛИТЕРАТУРЫ

1. Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1983. – 320 с.

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

3. Дейт К. Руководство по реляционной СУБД DB2. – М.: Финансы и статистика, 1988. – 320 с.

4. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М.: Мир, 1991. – 252 с.

5. Кириллов В.В. Структуризованный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с.

6. Мартин Дж. Планирование развития автоматизированных систем. – М.: Финансы и статистика, 1984. – 196 с.

7. Мейер М. Теория реляционных баз данных. – М.: Мир, 1987. – 608 с.

8. Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., – М.: Мир, 1985. Кн. 1. – 287 с.: Кн. 2. – 320 с.

9. Ульман Дж. Базы данных на Паскале. – М.: Машиностроение, 1990.–386 с.

10. Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 1984. – 294 с.

11. Цикритизис Д., Лоховски Ф. Модели данных. – М.: Финансы и статистика, 1985. – 344 с.