27

Cодержание

Введение…………………………………………………………………….…….2

1. Инфологическое проектирование….……………………………….….…….4

1.1 Анализ предметной области…………………………………….…….4

1.2 Построение ER-диаграммы……………………………………….…...5

2. Определение требований к операционной обстановке…………….….….…10

2.1 Системные требования к ЭВМ………………………………….…….10

2.2 Объем памяти под данные………………………………………….…10

2.3Аназиз характера и интенсивности запросов……………………..…..11

3. Выбор СУБД……………………………………………………………………12

4. Логическое проектирование БД……………………………………………....14

4.1 Преобразование ER-диаграммы в схему БД………………………....14

4.2 Нормализация……………………………………………………….…17

5. Физическое проектирование БД………………………………………..……..20

Заключение………………………………………………………………………..25

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

Введение

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

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

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

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

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

1. Инфологическое проектирование.

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

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

Главными функциями, выполняемыми автосалоном, является доставка необходимого автомобиля в зависимости от заказа.

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

Штат предприятия состоит из 7-ми человек: директор, менеджер, бухгалтер, продавец (2 человека), рабочий (2 человека).

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

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

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

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

1.2. Построение ER – диаграммы.

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

В настоящее время применяют проектирование с использованием метода "Сущность-связь"(entity–relation, ER – method), который является комбинацией предметного и прикладного методов и обладает достоинствами обоих.

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

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

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

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

1) Клиенты (номер заказа, ФИО, контактный телефон, адрес);

2) Автомобили (модель, марка, код автомобиля, тип кузова, год выпуска);

3) Поставщики (код поставщика, название фирмы, адрес, контактный телефон, ФИ партнера);

4) Сотрудники (табельный номер, ФИО, год рождения, данные паспорта, должность);

5) Комплектация (код комплектации, КПП, АБС, АПС, салон, эл. пакет);

6)Технические характеристики (модель, мощность двигателя, крутящий момент, время разгона, количество мест, расход бензина, габаритные размеры, масса);

7) Автосалон (табельный номер, код поставщика, номер заказа, код автомобиля).

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

Под понятием «сущность» в модели понимается некоторая абстракция реально существующего объекта процесса или явления.

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

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

Существует три основных класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей – обозначения.

Стержневая сущность (стержень) – это независимая сущность, которая не является ни ассоциацией, ни обозначением, ни характеристикой. Такие сущности имеют независимое существование, хотя они и могут обозначать другие сущности. Ассоциативная сущность (ассоциация) – это связь вида "многие-ко-многим" между двумя или более сущностями или экземплярами сущности. Ассоциации рассматриваются как полноправные сущности, они могут: участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности; обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь.

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

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

Определим классы для наших сущностей. Стержневыми сущностями будут являться следующие: клиенты, поставщики, автомобили, сотрудники - эти сущности, согласно определения, имеют независимое существование. Ассоциацией в нашей базе данных будет сущность автосалон. Эта сущность имеет связь вида «многие-ко-многим». Характеристикой будут являться сущности комплектация и технические характеристики.

На основании вышеизложенного построим полную инфологическую модель базы данных «АВТОСАЛОН» и изобразим ее в виде ER – диаграммы. ER диаграмма представлена на рисунке 1.

N 1

1 1

N

N

N

1

1 1

1

N

Рис.1 ER-диаграмма

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

2.1 Системные требования к ЭВМ, предъявляемые СУБД.

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

Объектом нашего исследования является автосалон. Цель нашего исследования – частичная автоматизация управления автосалоном, т.е. создание базы данных, которая позволяет хранить и перерабатывать информацию.

Минимальные требования к ПК:

1) ПК с процессором не менее чем Pentium 500МГц.

2) Винчестер объемом не менее 10 Гб.

3) Наличие не менее 128 Мб оперативной памяти.

4) ОС Windows 98se.

5) Наличие приложения Microsoft Office 2000 Access.

Проектирование проводилось в СУБД Access 2000 на ПК с процессором Athlon XP 2500 +, винчестером объемом 120 Гб, 512 Мб оперативной памяти. В результате получена программа, при внедрении которой предприятие сэкономит время, а значит и деньги; упростится работа директора и менеджера этого автосалона.

2.2 Объём памяти, отводимой под данные

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

Рассчитаем мощность кортежей для таблицы «Автомобили».

Максимальное значение символов, которое может содержаться в одной строчке столбца «Тип кузова» – 15, столбца «Марка» -15 символов, столбца «Модель» - 15 символов, столбца «Код комплектации» - 3 символа, столбец «Год выпуска» - 7 символов. Следовательно, одна запись сущности будет соответствовать 55 байтам, но так как таблица «Автомобили» будет содержать 100 записей, то мощность картежа

М_Т1=55∙100=550 байт.

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

- для таблицы «Поставщики» имеем

М_Т2=54∙20=1080 байт;

- для таблицы «Клиенты»

М_Т3=40∙1000=4000 байт;

- для таблицы «Комплектация»

М_Т4=45∙50=2250 байт;

- для таблицы «Технические характеристики»

М_Т5=80∙100=8000 байт;

- для таблицы «Сотрудники»

М_Т6=55∙6=330 байт;

Тогда общий объем памяти, отводимый под данные БД равен

М_Т= М_Т1 +М_Т2+ М_Т3+ М_Т4+ М_Т5+ М_Т6= 15660 байт.

2.3 Анализ характера и интенсивности запросов.

Так как клиенты автосалона это небольшой круг людей, следовательно, продажи будут достигать 100 - 150 автомобилей в год. Поэтому интенсивность запросов будет невысокая.

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

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

В настоящее время существует большое количество программных продуктов, в которых можно реализовать спроектированную базу данных. Самыми популярными СУБД на сегодняшний день являются: «1С предприятие», dBASE, Microsoft FoxPro, Paradox, Microsoft Access.

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

FoxPro отличается высокой скоростью, имеет встроенный объектно-ориентированный язык программирования с использованием xBase и SQL, диалекты которых встроены во многие СУБД. Однако она (как и dBASE) не обладает средствами соблюдения целостности данных в отличие от более медленной СУБД Access. СУБД Paradox и Access имеют средства, реализующие такие возможности, как уникальность первичных ключей, ограничение операций, приводящих к нарушению ссылочной целостности, каскадное обновление и удаление информации. С точки зрения безопасности, наиболее предпочтительней СУБД dBASE и Access. СУБД dBASE имеет самый высокий уровень безопасности данных. А Access позволяет использовать такие средства как: установка пароля для индивидуальных пользователей и присвоение различных прав доступа отдельно таблицам, запросам, отчётам, макрокомандам или новым объектам на уровне пользователя.

В качестве системы управления базами данных (СУБД) для реализации поставленной задачи остановимся на процессоре данных MSDE (Microsoft Data Engine), входящем в состав Microsoft Office 2000. В качестве средства разработки базы данных делаем выбор в пользу Access 2000 также входящего в Microsoft Office 2000. Почему именно такой выбор?

• Microsoft Office 2000 распространенный программный продукт, установленный на компьютерах многих компаний.

• Решения, созданные в Access легко интегрируются в другие приложения Microsoft Office 2000: MS Word, MS Excel и другие. Подготовленный в проекте Access отчет легко может быть перенесен в другие приложения Office.

• Решения на базе Access + MSDE легко переносятся под управление MS SQL Server. Это означает, что приложение созданное в Access для использования с MSDE имеет высокий уровень масштабируемости.

По умолчанию Access хранит все объекты данных и интерфейса в одном общем файле MDB. В Access 2000 появилась мощная технология построения приложений – проекты Access (Access Data Project, ADP). В ней используется файл нового формата (ADP), который заменил базу данных Jet в части хранения объектов приложения (форм, отчетов макросов и модулей). Хранение и обработка данных возложены на SQL Server, к которому приложение подключается непосредственно через OLE .