Логическое проектирование баз данных

Основные данные о работе

Содержание

Основные данные о работе              1

Содержание              2

Введение              3

Основная часть              5

1 Основы проектирования реляционных баз данных              5

2 Логическое проектирование баз данных              15

Заключение              32

Глоссарий              36

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

Приложения              40

Введение

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

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

В развитии АИС можно выделить два поколения.

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

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

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

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

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

2.        Критерии, влияющие на структуру и проектирование баз данных.

3.        Методика сбора данных и поддержание баз данных.

4.        Экономические аспекты управления базами данных.

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

Основная часть

1 Основы проектирования реляционных баз данных

1.1 Этапы проектирования

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

В процессе проектирования баз данных часто выделяют три этапа.

Этап 1. Построение концептуальной модели предметной области.

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

Этап 2. Логическое проектирование – преобразование созданной концептуальной модели в концептуальную схему, реализуемую конкретной СУБД.

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

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

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

1.2 Построение концептуальной модели предметной области

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

Рассмотрим некоторые средства концептуального моделирования.

ER-модель

ER-модель (Entity-Relationship – сущность-связь) была предложена П. Ченом в 1976 г. нформация о содержании предметной области в рамках модели изображается в структурированном графическом виде (ER-диаграмма).

Основными конструкциями модели являются сущности и связи.

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

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

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

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

С помощью связей на ER-диаграмме отображается взаимодействие между сущностями. Связь изображается ромбом, соединяющим связываемые сущности, внутри которого указывается вид связи (обычно выражается глаголом). Например, сущности Директор и Сотрудник могут быть соединены связью Руководит. Между двумя сущностями может быть установлено несколько связей: Продавец – Продает – Товар, Продавец – Фасует – Товар, Продавец– Учитывает – Товар. Количество сущностей, участвующих в связи, определяет ее степень. Связь Руководит между сущностями Директор и Сотрудник имеет степень, равную двум.

Связи могут иметь разный характер:

•      «один к одному» (1 : 1) – один экземпляр сущности Директор связан с одним экземпляром сущности Магазин;

•      «один ко многим» (1 : М) – один экземпляр сущности Директор связан со многими экземплярами сущности Продавец;

•      «многие ко многим» (М : М) – многие экземпляры сущности Продавец связаны со многими экземплярами сущности Товар.

Символы, указывающие на характер связи (1 или М), отображаются на ER-диаграммах рядом со связанными сущностями.

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

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

На рис. 1 представлен фрагмент ER-диаграммы, отображающей работу магазина.

Сущность Работник имеет два подтипа – Директор и Продавец. Между сущностями Магазин и Работник связь имеет характер «один ко многим» (один магазин обслуживается многими работниками), между сущностями Директор и Продавец – «один ко многим» (один директор руководит многими продавцами), между сущностями Продавец и Товар – «многие ко многим» (несколько продавцов продает множество разных товаров). Класс принадлежности большинства связей является обязательным. Он является необязательным для связи Фасует между сущностями Продавец и Товар со стороны сущности Продавец(не каждый продавец фасует товары) (см. рис. 1).

Функциональная модель данных

Эта модель была предложена Шипмэном в 1981 г.

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

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