Книжный магазин

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

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

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

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

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

 

        2. ВЫБОР СУБД.

       Как уже было написано, для своей работы я использовал СУБД Access 2003.

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

     Основные  компоненты MS Access:

- построитель  таблиц;

- построитель  экранных форм;

- построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);

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

     Они могут вызывать скрипты на языке VBA, поэтому MS Access позволяет разрабатывать  приложения и БД практически «с нуля»  или написать оболочку для внешней  БД.

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

     Таблицы в Access можно создавать разными способами. Для каждой таблицы задается ее имя. Максимальное число знаков в имени таблицы равно 64. ^[6]

     Таблица состоит из полей. Максимальное число  полей в таблице – 255. Для каждого  поля задается его имя. Максимальное число знаков в имени поля также  равно 64. Каждое поле имеет определенный тип данных. В зависимости от способа создания таблицы тип данных может задаваться создателем таблицы путем явного выбора, определяться исходя из типа вводимых данных или определяться типом данных, служащих источником данных при создании данной таблицы.

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

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

     Каждое  поле имеет набор свойств. Состав этого набора зависит от данных этого поля. ^{[1, с. 137-139]}

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

   -    Не должно быть повторений  и между таблицами.

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

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

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

   -   Каждое поле должно быть связано с темой таблицы.

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

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

 

3. ПОСТРОЕНИЕ ИНФОЛОГИЧЕСКОЙ(КОНЦЕПТУАЛЬНОЙ) МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ. 

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

 Этапы  создания концептуальной модели:

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

     1.2. Определение типов связей.

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

и связей.

     1.4. Определение доменов атрибутов.

     1.5. Определение атрибутов, являющихся  потенциальными и

первичными  ключами.

     1.6. Специализация или генерализация  типов сущностей (необязательный  этап).

     1.7. Создание диаграммы "сущность-связь".

     1.8. Обсуждение локальных концептуальных  моделей данных с

конечными пользователями. ^{[2, c. 263-265]}

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

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

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

     Проблема  представления семантики давно  интересовала разработчиков, и в  семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLeon) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель «сущность—связь», предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена «сущность—связь», или «Entity Relationship», стала фактическим стандартом при инфологическом моделировании баз данных. Общепринятым стало сокращенное название ER-модель, большинство современных CASE-средств содержат инструментальные средства для описания данных в формализме этой модели. Кроме того, разработаны методы автоматического преобразования проекта БД из ER-модели в реляционную, при этом преобразование выполняется в даталогическую модель, соответствующую конкретной СУБД. Все CASE-системы имеют развитые средства документирования процесса разработки БД, автоматические генераторы отчетов позволяют подготовить отчет о текущем состоянии проекта БД с подробным описанием объектов БД и их отношений как в графическом виде, так и в виде готовых стандартных печатных отчетов, что существенно облегчает ведение проекта.

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

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

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

     В основе ER-модели лежат следующие  базовые понятия:

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

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

     Между сущностями могут быть установлены  связи — бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Связи делятся на три типа по множественности: один-к-одному (1:1), од и и-ко-многим (1:М), многие-ко-многим (М:М). Связь один-к-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности. Связь 1: М означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи. Связь «один-к-одному» (1:1) означает, что один экземпляр одной сущности связан только с одним экземпляром другой сущности, а связь «многие-ко-мно-гим» (М:М) означает, что один экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и наоборот, один экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. ^[5]

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

 

Рисунок 1. - Инфологическая модель базы данных компьютерного магазина.